clang16: Can't attach debugger with -gdwarf-4 (with reprex)

[FrancescElies]

Given this build script

# main.exe: can attach debugger
clang  -c -g  mylib.c -o mylib.o
llvm-ar rcs mylib.lib mylib.o
clang main.c -g -L. -lmylib.lib -o main.exe

# main_noattach.exe: I can't attach debugger
clang  -c -g -gdwarf-4  mylib.c -o mylib-noattach.o
llvm-ar rcs mylib-noattach.lib mylib-noattach.o
clang main.c -g -gdwarf-4 -L. -lmylib-noattach.lib -o main-noattach.exe

With clang version:

❯ clang --version
clang version 16.0.3
Target: x86_64-pc-windows-msvc
Thread model: posix

Code

// mylib.c
#include <stdio.h>

void hello() {
    printf("Hello, World (static lib)!\n");
}

// main.c
#include <stdio.h>
#include <windows.h>

void hello  ();

int main() {
  while (1){
    hello(); 
    Sleep(3000); 
  }
  return 0;
}

Why when attaching the llvm debugger with vscode to main.exe one hits breakpoints but not with main-noattach.exe?

Is this a vscode problem or a gdwarf-4 thing?

https://github.com/llvm/llvm-project/assets/6558089/24ec580e-e1a7-41a7-a9d0-dce0bfc1002f

Thanks in advance for your help

[dwblaikie]

"attaching the llvm debugger" - I guess that means lldb? Might be worth trying to reproduce it with lldb directly, to rule out some complications with vscode. And does it reproduce without building the intermediate static library?

[FrancescElies]

@dwblaikie thanks for your answer, probably making a fool out of myself here but I didn't even manage to set a breakpoint without gdwarf-4 flag.

Do you see by any chance what am I missing?

mylib on  master [+] via C v12.2.0-gcc
❯ bat simple_main.c
───────┬─────────────────────────────────────────────────
       │ File: simple_main.c
───────┼─────────────────────────────────────────────────
   1   │ // clang -g simple_main.c -o simple-main.exe
   2   │ // breakpoint set --file simple_main.c --line 7
   3   │
   4   │ int main() {
   5   │   int i;
   6   │   while (1) {
   7   │     i += 1;
   8   │   }
   9   │   return i;
  10   │ }
───────┴─────────────────────────────────────────────────

mylib on  master [+] via C v12.2.0-gcc
❯ clang -g simple_main.c -o simple-main.exe

mylib on  master [+] via C v12.2.0-gcc
❯ lldb simple-main.exe
(lldb) target create "simple-main.exe"
(lldb) Current executable set to 'C:\s\mytest\mylib\simple-main.exe' (x86_64).
(lldb) breakpoint set --file simple_main.c --line 7
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb)

[dwblaikie]

Yeah, not sure what the problem/issue is there - maybe something to do with windows support. Works for me (on linux, though that may be unrelated)? I'm not sure whether what you're doing is producing DWARF on windows, and if so, how it goes when it's put in Windows object files... but I guess maybe that's fine?

$ cat test.c
int main() {
  int i;
  while (1) {
    i += 1;
  }
  return i;
}
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/usr/local/google/home/blaikie/dev/scratch/a.out' (x86_64).
(lldb) breakpoint set --file test.c --line 4
Breakpoint 1: where = a.out`main + 11 at test.c:4:7, address = 0x000000000000113b

[FrancescElies]

ℹ️ lldb can't seta breakpoint but vscode seems to manage that.

[dwblaikie]

Sorry, might be out of my depth on the Windows side of things.

[FrancescElies]

No worries, thanks for your replies, do you know if this is the right channel to ask or should I try luck somewhere else?

[dwblaikie]

Not sure - I don't know enough to know how/whether to diagnose this as a bug. Might be you could try LLVM discord (live-ish chat) or discourse (web forum), or maybe reddit?

[FrancescElies]

@dwblaikie After help from a colleague who pointed me out to this stackoverflow thread I managed to get lldb working. One now needs to register msdia140.dll, this was at some point added to the docs but can't tell when exactly we are pretty sure lldb used to work without that a while ago.

Anyhow, see below a successful debug session.

mylib on  master [+?] via C v12.2.0-gcc
❯ clang -g simple_main.c -o simple-main.exe

mylib on  master [+?] via C v12.2.0-gcc
❯ lldb simple-main.exe
(lldb) target create "simple-main.exe"
(lldb) Current executable set to 'C:\s\mytest\mylib\simple-main.exe' (x86_64).
(lldb) b simple_main.c:7
Breakpoint 1: where = simple-main.exe`main + 9 at simple_main.c:7, address = 0x0000000140006e79
(lldb) r
(lldb) Process 10552 launched: 'C:\s\mytest\mylib\simple-main.exe' (x86_64)
Process 10552 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ff6f0a26e79 simple-main.exe`main at simple_main.c:7
   4    int main() {
   5      int i;
   6      while (1) {
-> 7        i += 1;
   8      }
   9      return i;
   10   }
(lldb)

Same code as soon as it's compiled with -gdwarf-4 it breaks💥, so the problem is not limited to vscode debugging.

❯ clang -g -gdwarf-4 simple_main.c -o simple-main.exe

mylib on  master [+?] via C v12.2.0-gcc
❯ lldb simple-main.exe
(lldb) target create "simple-main.exe"
(lldb) Current executable set to 'C:\s\mytest\mylib\simple-main.exe' (x86_64).
(lldb) b simple_main.c:7
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
(lldb) Process 20168 launched: 'C:\s\mytest\mylib\simple-main.exe' (x86_64)

Does this help or there is anything else I could provide?

[llvmbot]

@llvm/issue-subscribers-debuginfo

[llvmbot]

@llvm/issue-subscribers-lldb

[FrancescElies]

I also suspect #62350 couldn’t start lldb because of the same reason, msdia140.dll not registered.