When/how to build separate debug symbol files

[Ken Thomases]

On Jun 24, 2015, at 7:58 PM, Charles Davis <cdavis5x at gmail.com> wrote:

> On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken at codeweavers.com> wrote:
>> 
>> 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.

OK.  Do they get any help in applying objcopy to Wine's binaries?  That is, is there anything in Wine's build system into which they hook?  Or do they just need to manually identify the binaries somehow?  (Not saying it's necessarily hard, just wondering what the right way to do it is.)

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

Yup.  I was aware of that.

> This gives packagers time to objcopy(1) the DWARF data before it’s stripped away.

I was thinking that the "make install" step would both be the opportunity to apply objcopy and also be a way to identify the files on which to apply it.  Basically, anything on which INSTALL_PROGRAM is used.  They might even do it with a cleverly-specified STRIP command.


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

OK, interesting, but I don't think I want to rely on that.  I think it's best to figure out when and how to call dsymutil and do that explicitly from Wine's build system.

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

Yes, sure, I can do it manually (both deciding to do it and figuring out what to do it to).  I'm hoping to find the right way to automate it.

Regarding whether stripping is done on OS X, Wine seems to use GNU install (if I've properly understood).  Wine ships tools/install-sh and uses that.  However, it seems that one must specify INSTALL_PROGRAM_FLAGS=-s in order to make it actually try to strip.  A simple "make install" doesn't by default.  And, then, OS X's strip throws errors when used without options, so you have to specify STRIP="strip -x".


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

Yes, that's what I meant by "isn't easily accessible". ;)  Not impossible, just not easy.

Thanks for your input,
Ken