| Issue |
172032
|
| Summary |
[lldb] ObjectFileELF uuid can be computed from a .gnu_debuglink section that does not change between builds
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
the-sushi
|
At least, that's how it appears. When linking with lld/mold, my executables get a .gnu_debuglink section that looks like this:
```
String dump of section '.gnu_debuglink':
[ 0] Scrt1.o.debug
[ 12] %Tcrti.o.debug
[ 24] y�v�crtbeginS.o.debug
[ 40] crtendS.o.debug
[ 50] A6^P�crtn.o.debug
[ 66] h1
```
Which looks quite messed up, but is very similar to the gnu_debuglink mentioned at the very end of [this bugzilla issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1485556). This section is the same for every build.
As a last resort it looks `ObjectFileELF::GetUUID` tries to generate its uuid from a crc of this section here:
https://github.com/llvm/llvm-project/blob/ec1bf9c56250803b434220d24d5035c121de72fa/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L903-L908
While debugging my project, if I rebuild the executable after having initially loaded it into lldb, further runs will show wildly incorrect source locations and to fix the issue I usually just restart lldb. After finding this, though, I added `-Wl,--build-id` to my link commands which seemed to workaround the issue.
Not sure if this is just an issue with how I build my projects, and this was on a somewhat outdated fork of lldb, though the code embedded looks mostly the same (`m_data` has just been made into some fancy pointer type). Once lldb rebuilds I will confirm if this is still an issue on latest.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
