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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
