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

[David Blaikie via lldb-commits]

dwblaikie 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.
> 
> 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.

>  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.

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