Given: enum foo { foo0, foo1, foo2, foo3 }; int main () { return foo0; } and compiled with -gdwarf-4 -fdebug-types-section, the .gdb_index generated by gold will record that the enum comes from the CU, whereas the .gdb_index generated by gdb will record the enum comes from the TU.
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.