[2/4] Handle copy relocations
Commit Message
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
Comments
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
@@ -21653,11 +21653,19 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
else if (attr2 && (DW_UNSND (attr2) != 0))
{
if (SYMBOL_CLASS (sym) == LOC_STATIC
- && (objfile->flags & OBJF_MAINLINE) == 0)
+ && (objfile->flags & OBJF_MAINLINE) == 0
+ && dwarf2_per_objfile->can_copy)
{
/* A global static variable might be subject to
- copy relocation. */
- sym->maybe_copied = dwarf2_per_objfile->can_copy;
+ copy relocation. We first check for a local
+ minsym, though, because maybe the symbol was
+ marked hidden, in which case this would not
+ apply. */
+ minimal_symbol *found
+ = (lookup_minimal_symbol_linkage
+ (SYMBOL_LINKAGE_NAME (sym), objfile));
+ if (found != nullptr)
+ sym->maybe_copied = 1;
}
/* A variable with DW_AT_external is never static,