Shipping core libraries with debug symbols
Johan Tibell
johan.tibell at gmail.com
Sun Jan 4 23:59:29 UTC 2015
What about keeping exactly what -g1 keeps for gcc (i.e. functions, external
variables, and line number tables)?
On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:
>
>
> Okay, I ran a little experiment - here's the size of the debug sections
> that Fission would keep (for base library):
>
> .debug_abbrev: 8932 - 0.06%
> .debug_line: 374134 - 2.6%
> .debug_frame: 671200 - 4.5%
>
> Not that much. On the other hand, .debug_info is a significant contributor:
>
> .debug_info(full): 4527391 - 30%
>
> Here's what this contains: All procs get a corresponding DWARF entry, and
> we declare all Cmm blocks as "lexical blocks". The latter isn't actually
> required right now - to my knowledge, GDB simply ignores it, while LLDB
> shows it as "inlined" routines. In either case, it just shows yet more
> GHC-generated names, so it's really only useful for profiling tools that
> know Cmm block names.
>
> So here's what we get if we strip out block information:
>
> .debug_info(!block): 1688410 - 11%
>
> This eliminates a good chunk of information, and might therefore be a good
> idea for "-g1" at minimum. If we want this as default for 7.10, this would
> make the total overhead about 18%. Acceptable? I can supply a patch if
> needed.
>
> Just for comparison - for Fission we'd strip proc records as well, which
> would cause even more extreme savings:
>
> .debug_info(!proc): 36081 - 0.2%
>
> At this point the overhead would be just about 7% - but without doing
> Fission properly this would most certainly affect debuggers.
>
> Greetings,
> Peter
>
> On 03/01/2015 21:22, Johan Tibell wrote:
> > How much debug info (as a percentage) do we currently generate? Could we
> just keep it in there in the release?
>
> _______________________________________________
> 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/20150104/e14fbd00/attachment.html>
More information about the ghc-devs
mailing list