When/how to build separate debug symbol files

[Charles Davis]

> On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken at codeweavers.com> wrote:
> 
> Hi,
> 
> I'm investigating how to best make Wine build and install debug symbol files on OS X.
> 
> My understanding is that, on Linux, the distros usually provide a separate package for a user to install Wine's debug symbols.  From recent work in dbghelp, I'm guessing such a package installs debug symbol files next to the corresponding binary or in a .debug subdirectory next to it.  Is that correct?
> 
> How do packagers generate such separate debug symbol files?
I think they either:
a) use split DWARF (-gsplit-dwarf option to GCC/Clang), which will give you *.dwo files; or
b) use objcopy(1) to extract the .debug_* sections from the final binaries into *.debug files.

I suspect it’s the second one; split DWARF (aka DWARF Fission) is relatively new, so I don’t think it’s widely used yet.
> How does this interact with stripping during building for the non-debug-symbol, normal Wine package?
Wine doesn’t run strip(1) until install time. That’s why we set the STRIPPROG environment variable: if install(1) is GNU install, it’ll pick that up and run the specified strip(1) program on the installed copies of any binaries. This gives packagers time to objcopy(1) the DWARF data before it’s stripped away.
> 
> The dsymutil depends on references from the linked binary to the original object files from which it was created.  Those references are in the STABS info.  So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references.
First, I’ll tell you that, under certain circumstances, it’s possible to get GCC or Clang to invoke dsymutil(1) for you. I haven’t yet completely worked out what those circumstances are—so far, I know that it will do this if you compile and link in one step, but I don’t know how to get it to do this automatically when linking objects with a __DWARF segment.

The other thing I’ll tell you is that, since strip(1) isn’t run until install time (and, in fact, probably won’t be run at all on Mac OS since we often use BSD install(1) there), you should be able to run dsymutil(1) at any time up to ‘make install’.

> A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user.  Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time.  Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space.
It’s actually possible to read the DWARF data out of the object files (if they’re still around). Both GDB and LLDB do this in the absence of a dSYM companion bundle/file. This is easier said than done, though. If you go this route, you’ll need to relocate the object files’ DWARF data (basically, doing what dsymutil(1) does) before making them available to clients.

Chip