[Lldb-commits] [lldb] [lldb] Add more ways to find the .dwp file. (PR #81067)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> > FWIW, I think we should be opinionated (& consistent with whatever gdb does, if it has some precedent here - if it is less opinionated, then maybe we have to be accepting) when it comes to whether x.debug goes with x.dwp or x.debug.dwp - we shouldn't support both unless there's some prior precedent that's unavoidable to support. It'd be better for everyone if there was one option we encourage people to follow. (so I think we shouldn't support (2) and (3) if we can help it - we should pick one)
> 
> There currently is no enforcement on any of this from the compiler or linker driver side and everyone must do the stripping of the executable and creating the .dwp file manually. Since there is no actual enforcement, it seems like we should support both IMHO. More on this below...
> 
> > I'm not sure I understand the "lldb loads .debug and needs to find .dwp" case. the .debug file usually only has the debug info, not the executable code, so you can't load it directly, right? (see the documentation in https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html - `objcopy --only-keep-debug foo foo.debug`).
> 
> If we have a build system that creates:
> 
> * `a.out` which is stripped and shipped for distribution
> * `a.out.debug` which contains debug info only with the skeleton units, address table, line tables, accelerator tables
> * `a.out.dwp` or `a.out.debug.dwp` which contains the .dwo files for `a.out.debug`
> 
> We might request to download debug info for this build using a GNU build ID or some other build number for say a symbolication server which wants to use LLDB. If we get this debug info, we might only download `a.out.debug` and the associated `.dwp` file (either `a.out.dwp` or `a.out.debug.dwp`). It would be a shame to require that we download the `a.out` binary as well just so that we can load this into a debugger and get the .dwp file to load automatically.

Ah, OK, yeah I can see how for symbolizing that could be done with just the .debug and .dwp files, without the original executable. Thanks for explaining. (I wouldn't've expected someone to use a /debugger/ in this case, rather than llvm-symbolizer, addr2line, etc - but don't object to a debugger supporting that functionality)

> If we don't fix this, then people will get confused and not know how to fix things and get full debug info to get loaded. No one besides debugger, compiler, and linker engineers and very few other people actually know what split DWARF does and or means and if they can't get things to work, they give up or waste time figuring out the magic things that need to happen to make us able to load the right debug info. So I prefer to allow things to work more seamlessly without trying to enforce something that is left up to users to do in the first place. I am someone that often responds to peoples posts when I am on call and I need to help people figure out how to load their debug symbols correrctl.

My concern with supporting a wider variety of naming conventions is the risk of fragmentation and more user confusion - if there's multiple naming conventions, there's a risk that some tools end up supporting some of them but not others, and users are confused why their files work with some tools and not others.

I think we'd be doing users a favor, in terms of focussing the ecosystem on fewer permutations, by being opinionated on how these things should be named.

We are going to be somewhat opinionated regardless (we are using /some/ naming convention rules to derive .dwp/.debug names from other names - so we're only haggling over how many different naming conventions we should support, not whether or not we should limit users - they'll always be limited to some set of rules we pick).

> 
> With split DWARF it is even worse because if they get the debug info file with the skeleton compile units but the .dwp file isn't named consistent with GDB conventions, then they can set file and line breakpoints and hit them, but as soon as they stop there, they get no variable information because the .dwo file doesn't get loaded. They don't know what a .dwo or a .dwp file is or why it is needed. We get a few posts a week with people trying to use split DWARF symbols and not being able to get things to work.

Yeah, it's certainly a cost that comes with the benefits of Split DWARF - they should get suitable warnings/error messages, and perhaps those should link to an article describing what they're talking about if necessary.

> So IMHO there is no harm in making all scenarios work without having to require some naming convention that isn't actually enforced by _any_ compiler or linker driver, and when things don't work, we put the pressure on the user to find some wiki somewhere that says "here is how you were supposed to do it" and figure out how to fix the issue themselves or by seeking help from us.

"all" scenarios can't work (because we have to be able to derive one name from another) It'll always require some naming convention be met - we're only haggling over how many naming conventions we should support. And I think the harm in making more naming conventions work, is the risk that users end up with a variet of naming conventions in use, and other tools that need to handle these cases might not learn all those conventions - and so there will be varying/confusing support across a variety of tools. 

I think we do users a favour by limiting the ecosystem to fewer conventions.

And in this case, I think that rule would be <basename>, <basename>.debug, and <basename>.dwp



https://github.com/llvm/llvm-project/pull/81067