Missing/broken ˋ__int128ˋ support

[MauriceKayser]

Environment

• OS and version: Windows 11
• VS Code: 1.104.1
• C/C++ extension: 1.27.7

Description

Display of __int128 values seems broken/not supported in cpptools (Windows) in comparison to lldb (Linux).

Reproduction

1. Create a new Rust binary project: cargo new crate_name
2. Modify src/main.rs:

   struct I64(i64);
   struct U64(u64);
   struct I128(i128);
   struct U128(u128);
   
   fn main() {
       let i64_1 = 123_i64;
       let i64_2 = I64(123);
       let i128_1 = 123_i128;
       let i128_2 = I128(123);
       let u128_1 = 123_u128;
       let u128_2 = U128(123);
       let u64_1 = 123_u64;
       let u64_2 = U64(123);
       println!();
   }
   

3. Set a breakpoint at println!() and debug the program by clicking on the "Debug" label next to fn main().

Expected result (output of lldb on Linux)

Variables
  Locals
    i64_1  = 123        (long)
    i64_2  = {__0:123}  (crate_name::I64)
      __0  = 123        (long)
    i128_1 = 123        (__int128)
    i128_2 = {__0:123}  (crate_name::I128)
      __0  = 123        (__int128)
    u128_1 = 123        (unsigned __int128)
    u128_2 = {__0:123}  (crate_name::U128)
      __0  = 123        (unsigned __int128)
    u64_1  = 123        (unsigned long)
    u64_2  = {__0:123}  (crate_name::U64)
      __0  = 123        (unsigned long)

Actual result (output of cpptools on Windows)

Variables
  Locals
    i64_1  = 123                                 (__int64)
    i64_2  = {__0=123 }                          (crate_name::I64)
      __0  = 123                                 (__int64)
    i128_1 = An unspecified error has occurred.  (i128_1)
    i128_2 = {__0=??? }                          (crate_name::I128)
      __0  = <Unable to read memory>             (__0)
    u64_1  = 123                                 (unsigned __int64)
    u64_2  = {__0=123 }                          (crate_name::U64)
      __0  = 123                                 (unsigned __int64)
    u128_1 = An unspecified error has occurred.  (u128_1)
    u128_2 = {__0=??? }                          (crate_name::U128)
      __0  = <Unable to read memory>             (__0)

Differences (normalized)

• Lines 9 & 12: An unspecified error has occurred. instead of 123.
• Lines 10 & 13: ??? instead of 123.
• Lines 11 & 14: <Unable to read memory> instead of 123.
• Lines 9, 11, 12, 14: (variable name) instead of (type name), e.g. (__0) instead of (__int128).
• Lines 4, 7, 10, 13: Trailing whitespace after the variable value: {__0:123 } instead of {__0:123}.

More information

IDA (disassembler) extracts the following structs from the PDB:

00000000 struct crate_name::I64 // sizeof=0x8
00000000 {
00000000     __int64 __0;
00000008 };

00000000 struct crate_name::U64 // sizeof=0x8
00000000 {
00000000     unsigned __int64 __0;
00000008 };

00000000 struct crate_name::I128 // sizeof=0x10
00000000 {
00000000     __int128 __0;
00000010 };

00000000 struct crate_name::U128 // sizeof=0x10
00000000 {
00000000     unsigned __int128 __0;
00000010 };

[github-actions[bot]]

Thank you for reporting this issue. We’ll let you know if we need more information to investigate it. Additionally, if you're working with GDB/LLDB, please note that the code is open source at https://github.com/microsoft/MIEngine/wiki/Contributing-Code . Your contributions are always welcome and appreciated.

[MauriceKayser]

It seems the mentioned issues stem from the closed-source component vsdbg.exe:

When debugging the executable with a .vscode/launch.json with logging enabled, the following Debug Adapter Protcol command can be seen:

{
    "command": "variables",
    "arguments": {
        "variablesReference": 1000
    },
    "type": "request",
    "seq": 14
}

Which leads to the following response from vsdbg.exe:

{
    "seq": 92,
    "type": "response",
    "request_seq": 14,
    "success": true,
    "command": "variables",
    "body": {
        "variables": [
            {
                "name": "i64_1",
                "value": "123",
                "type": "__int64",
                "presentationHint": {
                    "kind": "data"
                },
                "evaluateName": "i64_1",
                "variablesReference": 0,
                "memoryReference": "0x000000000000007B"
            },
            {
                "name": "i64_2",
                "value": "{__0=123 }",
                "type": "crate_name::I64",
                "presentationHint": {
                    "kind": "data",
                    "attributes": [
                        "readOnly"
                    ]
                },
                "evaluateName": "i64_2",
                "variablesReference": 1002
            },
            {
                "name": "i128_1",
                "value": "An unspecified error has occurred.",
                "presentationHint": {
                    "attributes": [
                        "readOnly",
                        "failedEvaluation"
                    ]
                },
                "evaluateName": "i128_1",
                "variablesReference": 0
            },
            {
                "name": "i128_2",
                "value": "{__0=??? }",
                "type": "crate_name::I128",
                "presentationHint": {
                    "kind": "data",
                    "attributes": [
                        "readOnly"
                    ]
                },
                "evaluateName": "i128_2",
                "variablesReference": 1003
            },
            {
                "name": "u64_1",
                "value": "123",
                "type": "unsigned __int64",
                "presentationHint": {
                    "kind": "data"
                },
                "evaluateName": "u64_1",
                "variablesReference": 0,
                "memoryReference": "0x000000000000007B"
            },
            {
                "name": "u64_2",
                "value": "{__0=123 }",
                "type": "crate_name::U64",
                "presentationHint": {
                    "kind": "data",
                    "attributes": [
                        "readOnly"
                    ]
                },
                "evaluateName": "u64_2",
                "variablesReference": 1004
            },
            {
                "name": "u128_1",
                "value": "An unspecified error has occurred.",
                "presentationHint": {
                    "attributes": [
                        "readOnly",
                        "failedEvaluation"
                    ]
                },
                "evaluateName": "u128_1",
                "variablesReference": 0
            },
            {
                "name": "u128_2",
                "value": "{__0=??? }",
                "type": "crate_name::U128",
                "presentationHint": {
                    "kind": "data",
                    "attributes": [
                        "readOnly"
                    ]
                },
                "evaluateName": "u128_2",
                "variablesReference": 1005
            }
        ]
    }
}

Could you kindly forward this issue to the maintainers of vsdbg.exe?

[sean-mcmanus]

@MauriceKayser Are you compiling with clang/llvm?

[MauriceKayser]

Not sure if I understand the question correctly, but the example program is compiled via cargo, which calls rustc, which uses LLVM internally AFAIK: https://rustc-dev-guide.rust-lang.org/overview.html#code-generation

rustc uses LLVM for code generation

Does that help?

[sean-mcmanus]

@MauriceKayser We're unlikely to add support for __int128 debugging with vsdbg.exe in the near future. I would recommend trying the LLDB DAP extension by LLVM for debugging if you want to do __int128 debugging (although I haven't confirmed that it works for that).

[MauriceKayser]

Can confirm that it does work with LLDB DAP on Windows. Maybe that hint could be added here: https://code.visualstudio.com/docs/languages/rust#_install-debugging-support Is there an issue that can be subscribed to for __int128 debugging support?

[sean-mcmanus]

@MauriceKayser The issue to subscribe to would be this issue. I'm not sure yet who the owner the Rust VS Code docs is...but theoretically anyone could submit a PR with a suggested doc fix. I'm not sure if CodeLLDB (mentioned in the docs) or LLDB DAP is the recommended debugger for Rust (or what the difference is between those).