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? Is it a special option (make target?) in Wine's build process? Or is it a post-processing step after Wine is built and installed to a staging directory? How does this interact with stripping during building for the non-debug-symbol, normal Wine package?
For what it's worth, I'm working on make dbghelp support DWARF-2 debug info on OS X https://bugs.winehq.org/show_bug.cgi?id=22384. On OS X, the normal link step does not transfer the DWARF-2 debug info from the object files to the file binary. Rather, you have to execute a separate command, dsymutil, to "link" the debug info, but that ends up in a separate file, not the binary.
So, the first part is figuring out when to invoke dsymutil and where to put the debug symbol file. The second part is having dbghelp find that debug symbol file. I think I have a handle on the second part. The first part is what I'm trying to figure out.
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.
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.
Thanks, Ken
On Jun 24, 2015, at 5:26 PM, Ken Thomases ken@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
On Jun 24, 2015, at 7:58 PM, Charles Davis cdavis5x@gmail.com wrote:
On Jun 24, 2015, at 5:26 PM, Ken Thomases ken@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
On Wed, Jun 24, 2015 at 06:26:31PM -0500, Ken Thomases 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?
For SUSE we install the debuginfo in places like:
/usr/lib/debug/usr/lib64/libusb-1.0.so.0.1.0.debug for e.g. the libusb 1.0 shared library. /usr/lib64/libusb-1.0.so.0.1.0
Other distros might do it differently.
How do packagers generate such separate debug symbol files? Is it a special option (make target?) in Wine's build process? Or is it a post-processing step after Wine is built and installed to a staging directory? How does this interact with stripping during building for the non-debug-symbol, normal Wine package?
It is standard macro hidden in our RPM build process. It happens after the regular package "make install" is done.
It extracts the debuginfo fully automatic, no packager attention required.
Basically it does objcopy of the debug sections for all libraries and binaries, and afterwards it does "strip --strip-unneeded"
The package build itself is not supposed to strip binaries.
CIao, Marcus
-
Charles Davis -
Ken Thomases -
Marcus Meissner