Re: Inquiry about Development Features and Integration of Source Code Version Control Systems
Hi Tobias, I wanted to provide an alternative solution that may work for you (with or without support from debuginfod). Support for reading source code directly from a code hosting service (such as GitHub) has been supported for years by Microsoft via SourceLink[1]. In 2018, a proposal[2] was submitted to the DWARF standard to include sourcelink information in the DWARF format. In 2022, a modification to the proposal[2] was accepted and is in the current working draft for DWARF6[3]. The proposal is to place the source URL for any file with an available URL in the DWARF information. There is still a lot of work to do. The DWARF6 specification needs to be published, compilers (or external tools) need to support adding the URLs into the DWARF info, and debuggers need to support downloading the source files. But it could provide a path for you (or debuginfod) to support reading directly from the upstream source repository. > Can you explain under what situations you think this would be helpful? I can only think about situations that involve closed source software. In my experience, companies shipping closed source software have restrictions about where source code can be placed. -Matt [1]: https://learn.microsoft.com/en-us/cpp/build/reference/sourcelink?view=msvc-170 [2]: https://dwarfstd.org/issues/181223.1.html [3]: https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/dwarf6-20240227-2154.pdf
Re: Inquiry about Development Features and Integration of Source Code Version Control Systems
> i.e., a situation where even an internal debuginfod instance cannot be > trusted with the source code, but some version control system can be? That was my thought exactly. On Wed, Apr 10, 2024 at 9:07 AM Frank Ch. Eigler wrote: > > Hi - > > > Support for reading source code directly from a code hosting service > > (such as GitHub) has been supported for years by Microsoft via > > SourceLink[1]. [...] > > Thanks for that reminder. Yeah, eventually that could be an alternate > way. > > > [...] > > > Can you explain under what situations you think this would be helpful? > > > > I can only think about situations that involve closed source software. > > In my experience, companies shipping closed source software have > > restrictions about where source code can be placed. > > i.e., a situation where even an internal debuginfod instance cannot be > trusted with the source code, but some version control system can be? > > > - FChE >
debuginfod client as GDB/LLDB Plugin
Hi all! I have been working on a GDB and LLDB python plugin that will bring debuginfod to older versions of GDB and LLDB. It's still in the early stages of development (no support for source loading, no support for Python 2...) but wanted to raise awareness of my work and say thank you for coming out with debuginfod! You can find it here: https://github.com/schultetwin1/gdbundle-debuginfod -Matt
Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Hi Mark, My apologies for bringing this up so late. I was just re-reading this thread while looking at how to find a .dwp for a given binary. > But I was personally assuming we would extend it to also to other things like > dwo IDs (which are again almost identical globally unique identifiers for > files) I'm concerned about using dwo IDs to index debuginfod. They are only 64-bits and there will be many more dwo IDs than build ids or supplemental file ids since there is 1 per compile unit. Assuming dwo IDs are randomly distributed, once we have ~600,000,000 dwo IDs we have a 1% chance of a collision. ~600,000,000 = sqrt(2 * 2^64 * 0.01) (I think I did that math right but forgive me if not). Maybe that's an ok number? (I tried to estimate the number of compile units in one distro's release, but do not have a good way of doing that quickly) What about using `/buildid/BUILDID/dwp` instead? This is not a perfect solution, since (currently) no one puts the build-id into the *.dwp file, but it does get around this collision problem. -Matt
Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Thanks for the thoughts! > AIUI, -gsplit-dwarf is more suitable for development/scratch builds > than for distro binaries. If distros agree, then I would not expect > .dwo files to show up in distro-wide debuginfod services, but rather > within developers' own build trees. That's a good point. My concerns are only valid if distros decide to start building packages using -gsplit-dwarf and dwp to package up the .dwo files into one .dwp file. I also agree that split dwarfs (split dwarves?) are more suitable for local builds than for distro builds. The one advantage I can think of that split dwarfs offer distro binaries is a faster build for larger packages (since dwp does not do all the relocations the linker would normally do). But I don't know enough about building packages to say what will happen in the future. > The hypothetical problem is collision between dwo/dwp files, not > between dwo/dwp and normal buildid dwarf files, right? That's correct. > In that case, are you talking about two levels of indexing (buildid > of final linked binary + dwo_id)? I was suggesting one level of indexing. The buildid of the final linked binary would be used to reference the dwp file directly. This solution would not work for individual dwo files. For individual dwo files we could still use the dwo_id as they should only be for local builds. -Matt
