i8 and u8 not correctly shown in MSVC debugger

[Boddlnagg]

Compiling the following program with the MSVC toolchain and the running it in the MSVC debugger shows that there is some problem with inspecting values of type i8 and u8 (this was originally found while investigating #36503):

fn main() {
    let value_i8:  i8  = -1;
    let value_i16: i16 = -2;
    let value_i32: i32 = -3;
    let value_i64: i64 = -4;

    let value_u8:  u8  = 1;
    let value_u16: u16 = 2;
    let value_u32: u32 = 3;
    let value_u64: u64 = 4;

    let value_f32: f32 = 5.;
    let value_f64: f64 = 6.;


    let slice_u8: &[u8] = &[1,2,3];
    let slice_i8: &[i8] = &[1,2,3];
    let slice_u16: &[u16] = &[1,2,3];
    let slice_i16: &[i16] = &[1,2,3];

    // Without these, the values would be optimized away
    println!("{} {} {} {}", value_i8, value_i16, value_i32, value_i64);
    println!("{} {} {} {}", value_u8, value_u16, value_u32, value_u64);
    println!("{} {}", value_f32, value_f64);
    println!("{:?} {:?} {:?} {:?}", slice_u8, slice_i8, slice_u16, slice_i16);
}

The screenshot shows that the problem also appears for &[u8] and &[i8], where the debugger can't show the pointer (data_ptr).

[alexcrichton]

cc @michaelwoerister

[Boddlnagg]

Please forget what I first wrote here. I had an outdated PDB. Still, it led me on the right track:
cvdump (from https://github.com/Microsoft/microsoft-pdb/) says that the typeindex of both value_i8 and value_i16 is 0x0011 of value_i8 is 0x0068 and of value_u8 is 0x0069, which according to https://github.com/Microsoft/microsoft-pdb/blob/master/include/cvinfo.h corresponds to

T_INT1 = 0x0068, // 8 bit signed int
T_UINT1 = 0x0069, // 8 bit unsigned int

When I manually patch the PDB to use the following instead, it works better (it shows the value, but it interprets it as an ASCII character, which it should not ... ideally it should probably show the real Rust typenames, right?):

T_CHAR = 0x0010, // 8 bit signed
T_UCHAR = 0x0020, // 8 bit unsigned

The slices can be patched separately in a similar way.

The question remains where these typeindices are coming from ...

[Boddlnagg]

Looks like it's coming from the translation of DWARF to CodeView DebugInfo in LLVM, so it's really an LLVM issue: https://github.com/llvm-mirror/llvm/blob/864e0ffb0eb47f848aca60d1f08fc2962fbb5009/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp#L1223-L1240 (the Byte and SByte types are the (arguably) "wrong" ones)

[michaelwoerister]

@Boddlnagg That's some nice detective work there :)

From what I see in cvinfo.h, the given typeindices actually seem to be reasonable. i8 and u8 are signed and unsigned integers after all. It would be interesting what MSVC itself emits for an uint8_t, for example.

[michaelwoerister]

OK, so MSVC seems to emit char types for those:

This code:
uint8_t variable1 = 1;
int8_t variable2 = 2;

Results in this PDB:
(0003E8)  S_BPREL32: [FFFFFFEF], Type:       T_CHAR(0010), variable1
(0003FC)  S_BPREL32: [FFFFFFFB], Type:      T_UCHAR(0020), variable2

I'd still consider it a bug in the MSVC debugger rather than in LLVM.

[Boddlnagg]

I agree that the MSVC debugger behavior is unexpected, but LLVM has already changed a usage of T_INT8 to T_QUAD (both represent 64-bit integers), probably because of a similar issue, so it looks like the T_INTx types are just not supported very well by the debugger.

The debugger module for using GDB directly inside VS (https://github.com/Microsoft/MIEngine) does the same thing by the way (although coming from the opposite direction, since it uses the DWARF data directly), you can see this when using VisualRust, and compile with the GNU toolchain:

[michaelwoerister]

I submitted a bug with LLVM: https://llvm.org/bugs/show_bug.cgi?id=30552
Thank you so much for looking into this, @Boddlnagg!

[Boddlnagg]

A fix has landed in LLVM :)

[michaelwoerister]

I consider this fixed.

[gurry]

Guys can you please confirm if this issue is actually fixed? I'm still seeing it with rustc 1.14:

rustup show output:

[sfackler]

Reopening since the LLVM fix has not propagated to our fork.

[gurry]

Hi guys, Any indication whether a fix will make it into 1.15 or not? I'm not sure what the policy is on updating rust's mirror of LLVM. If someone can help me I can do the rebase or merge. Or do we wait for the next official release of LLVM to come out before we do the merge?

[gurry]

As per information provided by @brson, upgrade to next version of LLVM is in progress. The status can be tracked here: #37609

[MichaelNecio]

#37609 has been closed. Can this issue be closed now too?

[Boddlnagg]

I can confirm that this is working now in my test program with the latest nightly (rustc 1.19.0-nightly (f89d8d184 2017-05-30))

[michaelwoerister]

Cool, thanks @Boddlnagg!