[2/4] Handle copy relocations

  Pedro> To be more correct, this depends on ABI, or how you compile your
Pedro> binary.  Compiling the main binary as PIC/PIE may or may not use
Pedro> copy relocations and use GOT accesses instead, for example.

Yes, thanks for mentioning that.

Pedro> I'm surprised to find no tests in this patch?

The existing Ada exception-catching tests cover this, so I didn't add a
new test.

Pedro>  FAIL: gdb.base/print-file-var.exp: hidden=1: dlopen=0: version_id_main=0: 'print-file-var-lib2.c'::this_version_id == v2

I haven't investigated the other failures yet, but I think this one in
particular is an existing bug in c-exp.y.  What happens is that this
does not actually look up the symbol from that source file!  Instead it
finds the symbol in print-file-var-lib1.c.

Pedro> But I'm wondering whether fixing the hidden=1 cases would fit
Pedro> with the design of your patch, or does that scenario require
Pedro> thinking about all this differently?

I think applying the appended probably makes sense.  This rules out
symbols where the corresponding minsym is hidden.

Tom
  

Tom> I haven't investigated the other failures yet, but I think this one in
Tom> particular is an existing bug in c-exp.y.  What happens is that this
Tom> does not actually look up the symbol from that source file!  Instead it
Tom> finds the symbol in print-file-var-lib1.c.

Digging a bit deeper, the culprit seems to be lookup_global_symbol.
I think this function should respect a block that's passed in.

However, this code also calls
gdbarch_iterate_over_objfiles_in_search_order and solib_global_lookup,
and now I wonder if one or both of these needs to be changed
as well.

For example, if stopped in the library, "print this_version_id" should
probably follow the expected-by-the-library-author lookup, but currently
I think will not.

Maybe windows_iterate_over_objfiles_in_search_order should just be the
default.  I am not sure.

Tom
  

Tom> Digging a bit deeper, the culprit seems to be lookup_global_symbol.
Tom> I think this function should respect a block that's passed in.

I managed to get the new test completely passing.

I changed basic_lookup_symbol_nonlocal to search the block's global
block, and I removed the long comments fro 2002-3 about why this isn't
done.  TBH I think all of that was just mistaken.

This change got to just 2 failures.  The last two were both the
"hidden0...main0" variants, which print:

get_version_1: &this_version_id=0x7ffff7fca010, this_version_id=104
get_version_2: &this_version_id=0x7ffff7fca010, this_version_id=104

So, I think for these the answer is to change the new get_symbol_address
to search all objfiles in order.  I'm slightly unhappy with this but it
seems correct enough.

I'm re-testing the series and will resubmit it once that's done,
assuming there aren't regressions.

thanks,
Tom