This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Work around binutils/15021
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, Cary Coutant <ccoutant at google dot com>, Sterling Augustine <saugustine at google dot com>
- Date: Thu, 17 Jan 2013 10:42:17 -0800
- Subject: Re: [RFA] Work around binutils/15021
- References: <yjt24nigsohy.fsf@ruffy2.mtv.corp.google.com> <87ehhjd7dk.fsf@fleche.redhat.com>
On Thu, Jan 17, 2013 at 9:52 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> Regression tested with gdb-generated .gdb_index version 7 (by hacking the
> Doug> gdb-under-test to generate version 7), version 8, with dwz, and with gold.
>
> I think index version bumps require a documentation update and also a
> binutils patch.
Blech. Must remember to type grep foo *.texinfo instead of *.texi.
> Doug> Work around binutils/15021
>
> IIUC, the version bump is part of the workaround for the gold bug,
> right? The idea being that gold will generate version 7 indices,
> causing gdb to take the "inclusion" path. (I'm just trying to make sure
> I understand what is going on.)
Yeah. In the end I may not be able to avoid always having to record
the inclusions.
But to handle an app with 10k CUs and 530k TUs I'd to know if I *can*
avoid it before something goes into a spec that makes it really hard
or impossible.
> Doug> + This is also used to work around a difference between the way gold
> Doug> + generates .gdb_index version <=7 and the way gdb does. Arguably this
> Doug> + is a gold bug.
>
> To me it doesn't seem arguable, but I'm curious to know what the case is
> for it not being a gold bug.
I don't have a strong enough opinion on this.
> Doug> @@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile
>
> Doug> for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)
> Doug> VEC_free (dwarf2_per_cu_ptr,
> Doug> - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs);
> Doug> + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs);
>
> If follow_die_sig can be called when one TU refers to another TU, then
> it seems like the TU could have a non-empty 'imported_symtabs', meaning
> that the loop here should also iterate over TUs.
Ah, righto. Revised patch to follow.