clayborg 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. With this change people _can_ load `a.out.debug` into LLDB and peruse the debug information and perform symbolication without having to download the original `a.out`, a file which is not required for symbolication. If we downloaded `a.out.debug` + `a.out.dwp`, unless a user knows to rename `a.out.dwp` to `a.out.debug.dwp`, or create a symlink, then they won't get any info from the .dwo files in the .dwp file. 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. 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. 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. 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
