Shipping core libraries with debug symbols

[Peter Wortmann]

The debian package seems to simply put un-stripped libraries into a 
special path (/usr/lib/debug/...). This should be relatively 
straight-forward to implement. Note though that from a look at the RPM 
infrastructure, they have a tool in there (dwarfread) which actually 
parses through DWARF information and updates paths, so there is possibly 
more going on here.

On the other hand, supporting -gsplit-dwarf seems to be a different 
mechanism, called Fission[1]. I haven't looked too much at the 
implementation yet, but to me it looks like it means generating copies 
of debug sections (such as .debug-line.dwo) which will then be extracted 
using "objcopy --extract-dwo". This might take a bit more work to 
implement, both on DWARF generation code as well as infrastructure.

Interestingly enough, doing this kind of splitting will actually buy us 
next to nothing - with Fission both .debug_line and .debug_frame would 
remain in the binary unchanged, so all we'd export would be some fairly 
inconsequential data from .debug_info. In contrast to other programming 
languages, we just don't have that much debug information in the first 
place. Well, at least not yet.

Greetings,
   Peter

[1] https://gcc.gnu.org/wiki/DebugFission


On 03/01/2015 00:18, Johan Tibell wrote:
> Hi!
>
> We are now able to generate DWARF debug info, by passing -g to GHC. This
> will allow for better debugging (e.g. using GDB) and profiling (e.g.
> using Linux perf events). To make this feature more user accessible we
> need to ship debug info for the core libraries (and perhaps the RTS).
> The reason we need to ship debug info is that it's difficult, or
> impossible in the case of base, for the user to rebuild these
> libraries.The question is, how do we do this well? I don't think our
> "way" solution works very well. It causes us to recompile too much and
> GHC doesn't know which "ways" have been built or not.
>
> I believe other compilers, e.g. GCC, ship debug symbols in separate
> files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then
> look up.
>
> -- Johan
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>