Re: [RFA] Work around binutils/15021

[Doug Evans <dje at google dot com>]

On Sat, Jun 8, 2013 at 9:04 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hello Doug,
>
> On Thu, 17 Jan 2013 00:21:29 +0100, Doug Evans wrote:
>> +     This is also used to work around a difference between the way gold
>> +     generates .gdb_index version <=7 and the way gdb does.  Arguably this
>> +     is a gold bug.  For symbols coming from TUs, gold records in the index
>> +     the CU that includes the TU instead of the TU itself.  This breaks
>> +     dw2_lookup_symbol: It assumes that if the index says symbol X lives
>> +     in CU/TU Y, then one need only expand Y and a subsequent lookup in Y
>> +     will find X.  Alas TUs live in their own symtab, so after expanding CU Y
>> +     we need to look in TU Z to find X.  Fortunately, this is akin to
>> +     DW_TAG_imported_unit, so we just use the same mechanism: For
>> +     .gdb_index version <=7 this also records the TUs that the CU referred
>> +     to.  Concurrently with this change gdb was modified to emit version 8
>> +     indices so we only pay a price for gold generated indices.  */
>
> what is the gold bug?
>
> According to the description I would expect from gold a line
>         [773] C: 1 [no symbol information]
>
> but there is a line similar to what contains a gdb-produced index 7/8.
>         [773] C: T0 [no symbol information]

Hi.
The gold "bug" is that, when using pubnames(/pubtypes) to generate the
index, gold doesn't have sufficient info to generate as "accurate" a
.gdb_index ("accurate" as in: the CU will have a DW_AT_GNU_pubtypes
attribute when it would be better if the TU had that attribute).
If those sections are missing then gold falls back to reading all the
debug info and using that to generate the index, and when it does that
it can generate a better index, and I'm guessing that's what you're
seeing.

> dwz currently supports at most version 7 so I am not sure if there is any
> change needed in dwz for version 8.

There is no change in the file format or semantics between 7 and 8, so
no change should be needed for dwz.
[I didn't know dwz dealt with .gdb_index - something for my TIL file. :-)]

>
>
> Thanks,
> Jan
>
>
> echo 'void f() {}' >tu0.C;echo 'class C {} c; int main() {}' >tu.C;for i in tu0 tu;do g++ -c -o $i.o $i.C -Wall -g -fdebug-types-section;done;g++ -o tu tu0.o tu.o -Wall;ld.gold -o tugold tu0.o tu.o --gdb-index;cp tu tu7;~/redhat/gdb-test-gdbindex7/gdb-add-index ./tu7;cp tu tu8;gdb-add-index tu8
>
> ==> tu0.C <== --- CU 0
> void f() {}
>
> ==> tu.C <== --- CU 1
> class C {} c; int main() {}
>
>
> readelf --debug-dump=gdb_index tu{7,8}   # There is no difference in these
> ------------------------------------------------------------------------------
> Contents of the .gdb_index section:
> Version {7,8}
>
> CU table:
> [  0] 0x0 - 0x48
> [  1] 0x49 - 0xb1
>
> TU table:
> [  0] 0x0 0x25 e5fcb7a195b2f213
>
> Address table:
> 00000000004005b0 00000000004005b6 0
> 00000000004005b8 00000000004005c3 1
>
> Symbol table:
> [489] main: 1 [global function]
> [754] int: 1 [static type]
> [773] C: T0 [global type]
> [1010] c: 1 [global variable]
> [1013] f: 0 [global function]
> ------------------------------------------------------------------------------
>
> readelf --debug-dump=gdb_index tugold
> ------------------------------------------------------------------------------
> Contents of the .gdb_index section:
> Version 5
>
> CU table:
> [  0] 0x0 - 0x48
> [  1] 0x49 - 0xb1
>
> TU table:
> [  0] 0x0 0x25 e5fcb7a195b2f213
>
> Address table:
> 00000000004000e8 00000000004000ee 0
> 00000000004000f0 00000000004000fb 1
>
> Symbol table:
> [489] main: 1 [no symbol information]
> [754] int: 1 [no symbol information]
> [773] C: T0 [no symbol information]
> [1010] c: 1 [no symbol information]
> [1013] f: 0 [no symbol information]
> ------------------------------------------------------------------------------