This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]
> Running gdb/testsuite/gdb.fortran/library-module.exp ...
> -PASS: gdb.fortran/library-module.exp: print var_i in lib
> +FAIL: gdb.fortran/library-module.exp: print var_i in lib
> -PASS: gdb.fortran/library-module.exp: print var_i in main
> +FAIL: gdb.fortran/library-module.exp: print var_i in main
Jan and I discussed this briefly on IRC, and here is what's happening.
The `lib' unit, which is compiled into a shared library, defines
a global named var_i. The main subprogram makes a reference to
that variable. What happens in our case is something that Jan called
copy-relocation. Quoting Jan:
From the naive programmer's point of view there is
single variable. But sure technically there are two
copies of that variable, due to copy-relocation. The
variable located in the .so file is dead and GDB must
not use it. But GDB has some bugs in it. Just
Looking at the debugging information, we indeed see 2 definitions
for that global variable:
. The first one is of course the global variable defined in
the `lib' module:
<1><d6>: Abbrev Number: 3 (DW_TAG_variable)
<d7> DW_AT_name : var_i
<df> DW_AT_MIPS_linkage_name: __lib__var_i
<ec> DW_AT_type : <0xfb>
<f0> DW_AT_external : 1
<f1> DW_AT_location : 9 byte block: 3 f8 8 20 0 0 0 0 0 (DW_OP_addr: 2008f8)
. And then the second instance, which is defined as an external
variable, but within the scope of the main subprogram (that's
the `<2>' on the first line:
<2><c9>: Abbrev Number: 3 (DW_TAG_variable)
<ca> DW_AT_name : var_i
<d2> DW_AT_MIPS_linkage_name: __lib__var_i
<df> DW_AT_type : <0x106>
<e3> DW_AT_external : 1
<e4> DW_AT_declaration : 1
There is no DW_AT_location for the second one, so I assume we go
through the minimal symbol table to get its actual address.
The Fortran implementation is taking advantage of the fact that
the executable is always going to be the first objfile being searched
by ALL_OBJFILES. My patch breaks that assumption. Jan also seems to
think that we may have the same sort of issue with C++ but we do not
have a reproducer.
I had some time to think this over during the weekend, and only see
two solutions:
(1) Back my patch out, which I think would be a real shame;
(2) Conditionalize my patch on the current language. If the current
language is Fortran, then loop over the objfiles as before.
I am a little unhappy about adding a reference to the current
language, but I don't see a way to infer any meaningful
language from the data we have in lookup_symbol_global (we have
the objfile's global block, and a domain_enum).
There is an intermediate solution, which is to always search the
main objfile first, and then the current DSO, and then the rest.
I think that'd be getting a little too complicated to explain to
the average user...
Thoughts?
--
Joel