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.

Sign up for GitHub

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

Jump to bottom

Support split debug information #60

Open
danielocfb opened this issue Feb 27, 2023 · 6 comments
Open

Support split debug information #60

danielocfb opened this issue Feb 27, 2023 · 6 comments
Assignees
@danielocfb
Labels
enhancement New feature or request

Comments

@danielocfb
Copy link
Collaborator

We should support split debug information.
@danielocfb
Copy link
Collaborator Author

danielocfb commented May 2, 2023 •
edited
Loading

This will likely come once we switch to using gimli.

Edit: Not meaning to imply that it will just magically happen, but more that gimli is a prerequisite.

@danielocfb danielocfb added the enhancement New feature or request label Jun 7, 2023
@danielocfb
Copy link
Collaborator Author

So it appears there is some overlap with #208. Specifically, as per my limited understanding, split DWARF is really a catch-all for:

  • objcopy --only-keep-debug [...]; strip --strip-debug [...]; objcopy --add-gnu-debuglink= [...] dance
  • dwo
  • dwp

We may have to support all three. I believe (but haven't tested), that the first one should already work (as it's not really a different/extended format), though we may need to support following debug links specifically. The other two require special handling.

@danielocfb danielocfb mentioned this issue Jun 15, 2023
Closed
@danielocfb danielocfb self-assigned this Jan 25, 2024
@r1viollet
Copy link
Contributor

I will add some of the use cases I encounter on split debug in case this helps with prioritization / testing.
Starting with some of the simpler strategies, from the same folder. When we install debug symbols in a .NET container, we result in situations where .dbg are next to the library

/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.0/libcoreclr.so
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.0/libcoreclr.so.dbg

The build-ids match, the gnu-debuglink points to libcoreclr.so.dbg

readelf -x .gnu_debuglink /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.0/libcoreclr.so
Hex dump of section '.gnu_debuglink':
  0x00000000 6c696263 6f726563 6c722e73 6f2e6462 libcoreclr.so.db
  0x00000010 67000000 9c5b2729                   g....[')

@d-e-s-o d-e-s-o mentioned this issue Apr 17, 2024
Open
5 tasks
@d-e-s-o d-e-s-o mentioned this issue Apr 29, 2024
Closed
@d-e-s-o
Copy link
Collaborator

d-e-s-o commented May 1, 2024

Thanks for the example! Debug link support is indeed most likely the first thing that will come here, as the DWARF format shouldn't be any different from what I understand.

Starting with some of the simpler strategies, from the same folder.

Do you have use cases where the debug information is contained in a different folder? My reading of the "spec" is that only a file name is stored in the link, no path. So in a first version I think the assumption will be that the .debug file has to reside next to the other one. But, if users wanted to have separate debug info located in a different folder, that would need to be made user configurable, I'd think.

@danielocfb
Copy link
Collaborator Author

Oh okay, seems as if readelf is doing the following:

$ readelf -wk /usr/lib64/libc.so.6
readelf: /usr/lib64/libc.so.6: Warning: could not find separate debug file 'libc.so.6-2.37-19.fc38.x86_64.debug'
readelf: /usr/lib64/libc.so.6: Warning: tried: /lib/debug/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: /usr/lib/debug/usr/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: /usr/lib/debug//usr/lib64//libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: /usr/lib/debug/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: /usr/lib64/.debug/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: /usr/lib64/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: .debug/libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: libc.so.6-2.37-19.fc38.x86_64.debug
readelf: /usr/lib64/libc.so.6: Warning: tried: DEBUGINFOD_URLS=
Contents of the .gnu_debuglink section:

  Separate debug info file: libc.so.6-2.37-19.fc38.x86_64.debug
  CRC value: 0xa55cda70

So it's looking in various "well known" directories...great.

@danielocfb
Copy link
Collaborator Author

FYI, Debug link support is coming with #665

danielocfb pushed a commit that referenced this issue May 7, 2024
@d-e-s-o @danielocfb
Hook up GNU debug link support to DwarfResolver
4249bb7 
This change adds debug link support to our DwarfResolver. Specifically,
when a DwarfResolver is created, we check whether the opened file
contains a debug link. If so, we try to find the target file it
represents in a list of known directories and then load the DWARF
information from there. If none of the directories contains the file,
the debug link will be silently ignored. The reason for this behavior is
that many distributions seem to distribute binaries with debug links in
them, but then make the linked debug information optional by having it
contained in a dedicated package.
There are many locations at which this functionality could fit it.
Considered candidates are: 1) ElfResolverData::elf_resolver(), 2)
ElfResolver itself, and 3) DwarfResolver (the approach taken). 1) is
somewhat nice because it keep the existing resolver simple and to the
point. However, it is insufficient, because we expose ElfResolver
publicly and we most certainly want to enable debug link support for
users. Implementation inside ElfResolver is possible, but it seems
inferior to putting everything into DwarfResolver: we only intend to
follow debug links if DWARF support is enabled and eventually we could
consider checking both the original ELF file as well as the linkee ELF
file as fallback options when no symbol is found. As such, DwarfResolver
seems like the most apt location.

Refs: #60

Signed-off-by: Daniel Müller <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@danielocfb danielocfb

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@d-e-s-o @r1viollet @danielocfb