Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lldb does not support gnu debuglink for PE/COFF files on Windows #54344

Closed
alvinhochun opened this issue Mar 12, 2022 · 2 comments
Closed

lldb does not support gnu debuglink for PE/COFF files on Windows #54344

alvinhochun opened this issue Mar 12, 2022 · 2 comments

Comments

@alvinhochun
Copy link
Contributor

First, compile something:

d:\temp>clang++ -Og -g test.cpp -o test1.exe

d:\temp>lldb -a x86_64 test1
(lldb) target create --arch=x86_64 "test1"
Current executable set to 'test1' (x86_64)
(lldb) l main
File: d:\temp\test.cpp
   1    #include <cstdio>
   2
   3    int main() {
[snip]
(lldb) q

Then split the debugging info to a separate file:

d:\temp>objcopy --only-keep-debug test1.exe test1.exe.debug

d:\temp>strip --strip-debug test1.exe

d:\temp>objcopy --add-gnu-debuglink="test1.exe.debug" test1.exe

Now lldb does not load the debug symbols:

d:\temp>lldb -a x86_64 test1
(lldb) target create --arch=x86_64 "test1"
Current executable set to 'test1' (x86_64)
(lldb) l main
error: Could not find function named: "main".
(lldb) q

gdb loads them fine:

d:\temp>D:\dev\toolchain\mingw\x86_64-11.2.0-release-posix-seh-rt_v9-rev1\bin\gdb.exe test1.exe
D:\dev\toolchain\mingw\x86_64-11.2.0-release-posix-seh-rt_v9-rev1\bin\gdborig.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test1.exe...
Reading symbols from d:\temp\test1.exe.debug...
(gdb) l main
1       #include <cstdio>
2
3       int main() {
[snip]
(gdb) q

Using llvm-mingw-20211002-ucrt-x86_64 toolchain from https://github.com/mstorsjo/llvm-mingw/releases/tag/20211002

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 12, 2022

@llvm/issue-subscribers-lldb

@alvinhochun
Copy link
Contributor Author

alvinhochun commented May 25, 2022

mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

The file CRC or the CRC value from the .gnu_debuglink section is now
used to calculate the module UUID as a fallback, to allow verifying that
the debug object does match the executable. Note that if a CodeView
build id exists, it still takes precedence. This works even for MinGW
builds because LLD writes a synthetic CodeView build id which does not
get stripped from the debug object.

The `Minidump/Windows/find-module` test also needs a fix by adding a
CodeView record to the exe to match the one in the minidump, otherwise
it fails due to the new UUID calculated from the file CRC.

Fixes llvm/llvm-project#54344

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D126367
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants