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

[Greg Clayton via lldb-commits]

clayborg wrote:

> > I am fine with telling people what to do and giving them a golden path to what is easiest for our debuggers. And I will suggest to everyone that they use `.debug` and `.dwp`, but if we want to only support this, this leaves the downloading of the `.debug` file requiring a rename from `.dwp` to `.debug.dwp` in order for it to work for people. So then everything in this patch should be supported to allow loading the `.debug` file with a `.dwp` like we will encourage people to do.
> 
> Not sure I follow - one of the scenarios mentioned in this patch is
> 
> "lldb loads which is stripped but has .gnu_debuglink pointing to .debug with skeleton DWARF and needs to find .debug.dwp"
> 
> I don't think we should support that, for instance - we should load `<exe>.dwp` in that case.

We currently have this happening here at Facebook all over the place. We have tools that convert DWARF to GSYM and they don't need the stripped executable at all, they
> 
> > It would also be nice if we do have a single `.debug` file that has debug info only, it would be nice to allow it and the `.dwp` file to be combined into a single file. There is no reason for them to be separate anymore once we have `a.out` stripped, it would be nice to only require `a.out.debug` which contains the `.dwp` sections inside of it already instead of requiring people to have two files needed for debug info.
> 
> Maybe? I figure once you've got to download one file, two isn't a substantial imposition... - it'd be a bit weird having a DWP file and a .debug file mashed up together, but can't see any reason it wouldn't work - with the logic of "check if this program has a cu_index in it, if so, treat it as a dwp, otherwise look for .dwp, otherwise look for the dwos".



> > > > I am fine with telling people what to do and giving them a golden path to what is easiest for our debuggers. And I will suggest to everyone that they use `.debug` and `.dwp`, but if we want to only support this, this leaves the downloading of the `.debug` file requiring a rename from `.dwp` to `.debug.dwp` in order for it to work for people. So then everything in this patch should be supported to allow loading the `.debug` file with a `.dwp` like we will encourage people to do.
> > > 
> > > 
> > > Not sure I follow - one of the scenarios mentioned in this patch is
> > > "lldb loads which is stripped but has .gnu_debuglink pointing to .debug with skeleton DWARF and needs to find .debug.dwp"
> > > I don't think we should support that, for instance - we should load `<exe>.dwp` in that case.
> > 
> > 
> > If the client strips the debug info first into "a.out.debug" and then runs llvm-dwp, they will end up with a "a.out.debug.dwp". We have clients that are doing this already and we want to support them.
> 
> OK, could we fix llvm-dwp to match the behavior, then? If the file has a .debug extension, strip that and add the .dwp extension.

Here people are not using ".debug", but are using ".debuginfo"... Again, nothing is enforced and people are left to use llvm-objcopy + llvm-dwp how ever they want. Getting a solution that does everything might be nice. Any thoughts on modifying llvm-dwp to be able to do all of this and provide some path for people where it can either just create a .dwp file for a given executable _or_ it can create a `.debug` file, strip the original file, and create a `.dwp` file?

> 
> > The compiler and linker drivers are staying out of this and we expect people to do this on their own, so this is what we end up with when there is no enforcement.
> 
> They aren't doing it on their own though - they're using llvm-dwp and its defaults (they're passing it a .debug file and getting a .debug.dwp file - it's the defaults you/we are worried about, and how to make other tools work well with those defaults). We can change those defaults if they don't work well/don't create a consistent environment.
> 
> > I am not sure why this is such a sticking point. Lets make the debugger work for people.
> 
> As I explained above - my concern is that supporting a wider variety of ways these files can be named/arranged means more variants that need to be supported across a variety of tooling (symbolizers and debuggers - not just LLVM's but binutils, etc too).
> 
> But that's my 2c - if LLDB owners prefer this direction, so be it. Wouldn't mind hearing some other people's perspectives on the issues around limiting variation here.

I am happy to hear any other opinions as well. I tend to want to make my life easier and ease the support burden I run into everyday where people that know nothing about split DWARF are trying to use it and failing and require tech support to make it work for them. I am happy to suggest a path to follow, in fact I am going to write up the best practices on a DWARF group here at work that I can point poeple to. 

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