This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reduce Dwarf Debug Size
- From: Ian Lance Taylor <iant at google dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, Lawrence Crowl <crowl at google dot com>, gcc-patches at gcc dot gnu dot org
- Date: 28 Feb 2007 18:26:57 -0800
- Subject: Re: Reduce Dwarf Debug Size
- References: <29bd08b70702271038id9865cfjd5528170d15d4282@mail.gmail.com> <796808AD-9E2E-4DD6-B817-2EFDDC1943D8@apple.com> <m3zm6y2deu.fsf@localhost.localdomain> <20070228220350.GA20232@caradoc.them.org> <m3r6s9x3kn.fsf@dhcp-172-18-118-213.corp.google.com> <DAF096F9-56E0-4646-B26A-AB45D65AE733@apple.com>
Mike Stump <mrs@apple.com> writes:
> On Feb 28, 2007, at 3:30 PM, Ian Lance Taylor wrote:
> > We should evaluate Lawrence's patch on its own merits: is it
> > useful, does it work, is it well-written.
>
> I'm game for this. I just worry that it works fine for all sample
> programs 500 lines or less and on nothing larger. I'd rather have a
> real user evaluate it in the context of a use pattern and tell us now
> it performs for them.
Lawrence has already evaluated it on Google's internal codebase, which
is more than 500 lines. Lawrence, could you send out the various
tables showing the percentage reductions for the various options?
Thanks.
> In the various scheme we've done, and we've done a few, leaving the
> debugging information in the .o files and having a utility to boost
> them out and save them, if you need to do that, is the current winner.
That approach doesn't work well for us because it requires you to keep
the .o files around if you want to do any debugging. And it requires
a reliable mapping from an executable back to the .o files used to
generate it. There are certainly scenarios where that can work.
Ian