This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Work around binutils/15021


>>>>> "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.

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.)

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.

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.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]