0

I'm using the LLDB extension for VSCode, and my variables typed as i8 are printed as characters. Both in the VSCode debugging panel, and when using print in the debugger console.

The variable is defined in the following way:

for y in 0..self.height

self.height being an i8.

I found How do I make the Xcode debugger show uint8_t values as numbers?, but even trying to add a fromat: type format add -f decimal int8_t, print y still outputs (signed char) $5 = '\a' instead of (let me consult the C escape sequences and the ascii chart...) 7.

Elias
  • 3,592
  • 2
  • 19
  • 42
  • 1
    https://stackoverflow.com/a/72119418/847382 – PitaJ May 05 '22 at 15:39
  • @PitaJ what exactly would be the solution? I can't seem to find it in that thread. – Elias May 05 '22 at 15:46
  • The answer there says to try the rust-analyzer extension to generate a launch profile. – PitaJ May 05 '22 at 19:31
  • @PitaJ I actually don't have a profile, I used rust-analyzer to run a single test. Anyway, adding a profile didn't help. I honestly don't see any configuration in the answer that would explain why the configuration would fix the problem. – Elias May 05 '22 at 20:43
  • When you type `print -T -- y` what gets output for the type? That's the string that your type formatter has to match against. You call the type i8 in your description, but your formatter is for int8_t? – Jim Ingham May 06 '22 at 21:47
  • @JimIngham I get `error: expression failed to parse: warning: Stopped in a C++ method, but 'this' isn't available; pretending we are in a generic context error: :1:2: use of undeclared identifier 'T' -T -- y` lol. Yes, my rust type is `i8` but when I searched the internet for "signed 8 bit integer c" I found `int8_t`. I basically assumed I had to use the c type, is that incorrect? – Elias May 07 '22 at 11:16
  • 1
    There are a couple of things here. (1) is to note that the support for Rust in lldb mostly consists of telling lldb that Rust is just like C++ and it should use the C++ type system & expression parser. That only sort of works, as you are finding. – Jim Ingham May 09 '22 at 16:24
  • 1
    But the type formatter matching is just a string compare against the type name. About the only language smarts the formatter matching has is that lldb will apply the match against all the elements of a typedef chain. But the matching is just either a string or regex matching on the type name. So if you want a formatter to match a type that is printed as "i8" that's the string you should feed to the type formatter. – Jim Ingham May 09 '22 at 16:28
  • @JimIngham so the debugger has no idea what the "original" type was in this case. As it's printed as 'signed char'? – Elias May 09 '22 at 20:43
  • I'm a little surprised by that, I thought the Rust support was sufficient to get types from the DWARF, but I've never had any direct experience with it. If you wanted to investigate further, you could dump the dwarf and see what the variable's type is there. Note that internally the Rust support in lldb is not much more than the one line that tells lldb to "pretend Rust is C++". But still, if the type was called 'i8' in the DWARF, we should have at least gotten that far. Maybe because this is a builtin type it gets treated differently? I'm not sure. – Jim Ingham May 09 '22 at 21:14
  • @JimIngham I'm afraid I'm not knowledgeable enough to extract "DWARF" data. I've found something called "llvm-dwarfdump", but couldn't figure out how to install it on windows. – Elias May 10 '22 at 12:03
  • llvm-dwarfdump is the tool you want. It should be part of the standard clang toolset, but I'm not aware of a way to get just dwarfdump. – Jim Ingham May 10 '22 at 17:07
  • @JimIngham So this is not the correct repo https://github.com/llvm/llvm-project ? Because it wasn't in there when I installed that. (At least not from the installer that I downloaded from the releases page, I see it in the source code, but I don't know if I have time to get into compiling c++ ATM ':D) – Elias May 11 '22 at 15:54
  • I'm not familiar with the windows distribution of the llvm tools. It might even be that you're using PDB instead, the clang tools can generate PDB as well as DWARF? But that's not an area I know much about. – Jim Ingham May 11 '22 at 16:16

2 Answers2

1

I know the thread is a few months old, but i encountered the same issue. I managed to fix it by going to the extension settings for CodeLLDB through the UI, and adding the command under Pre Run Commands. For some reason it doesn't work through the launch.json for me either.

For my use case I just added:

type format add --format u 'unsigned char'

JoachimEN
  • 11
  • 1
0

If anybody else runs into this, this might be of use:

frame variable --format d y

The variable will be printed as "decimal" indicated by the d. A list of all formats can (AFAIK) be found here: https://lldb.llvm.org/use/variable.html#id1.

After further trail and error, I figured out how to format all "signed char" in decimals, at least for the current session:

type format add --format d 'signed char'

This will work both when printing the variable in the debug console, and it will also update the values in the debug panel of VSCode immediately.

If anybody knows how to get this persistent, or even better, tell LLDB that the type is in fact not a char but an integer, please let me know.

Elias
  • 3,592
  • 2
  • 19
  • 42