Summary: | Gold generated index difference from gdb: symbols from TUs reference the containing CU | ||
---|---|---|---|
Product: | binutils | Reporter: | dje |
Component: | gold | Assignee: | Cary Coutant <ccoutant> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | ccoutant, saugustine |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
dje
2013-01-16 22:37:26 UTC
This is expected because the GCC-generated pubnames table has no way for some entries to refer to a CU, and others to refer to separate TUs. The only way to make this work would be to have separate pubnames/pubtypes tables for each TU, which would be impractical. We will eventually fix this with better accelerator tables. The example is incomplete, -gpubnames is needed as well. Also, If gold doesn't see a usable pubnames/pubtypes section it will fall back to reading all the debug info, and thus it can generate a better .gdb_index. There is another issue at play here: gold can end up processing both pubtypes/pubnames and reading the debug info, leading to the following in .gdb_index for the original example: bash$ gcc -g -Wl,--gdb-index -gpubnames -gdwarf-4 -fdebug-types-section 15021.c bash$ readelf -w a.out --> [190] foo0: 2 [no symbol information] T0 [no symbol information] [191] foo1: 2 [no symbol information] T0 [no symbol information] [192] foo2: 2 [no symbol information] T0 [no symbol information] [193] foo3: 2 [no symbol information] T0 [no symbol information] [661] foo: 2 [no symbol information] T0 [no symbol information] Note that there are two copies of each symbol. The one for the CU came from pubtypes and the one for the TU came from reading the debug info. |