Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]

[Joel Brobecker <brobecker@adacore.com>]

>  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