Shipping core libraries with debug symbols

[Johan Tibell]

How much debug info (as a percentage) do we currently generate? Could we
just keep it in there in the release?

On Sat, Jan 3, 2015 at 1:33 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:

>
>
> 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
>>
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150103/7d7aa6db/attachment-0001.html>