Re: [PATCH][gdb/symtab] Relocate call_site_htab

[Tom de Vries <tdevries@suse.de>]

n 10/1/21 3:15 AM, Simon Marchi wrote:
>> Ack, thanks.  I've put this through testing and ran into only two
>> regressions (so, this used to pass for me with unix/-fPIE/-pie):
>> ...
>> FAIL: gdb.trace/entry-values.exp: bt (1) (pattern 1)
>> FAIL: gdb.trace/entry-values.exp: bt (2) (pattern 1)
>> ...
>> while still fixing all the unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie
>> regressions.
>>
>> Fixed by:
>> ...
>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>> index bb5767aae67..fa775722afb 100644
>> --- a/gdb/dwarf2/read.c
>> +++ b/gdb/dwarf2/read.c
>> @@ -13517,7 +13517,8 @@ read_call_site_scope
>>                        sect_offset_str (die->sect_off), objfile_name
>> (objfile));
>>           else
>>             {
>> -             lowpc = gdbarch_adjust_dwarf2_addr (gdbarch, lowpc +
>> baseaddr);
>> +             lowpc = (gdbarch_adjust_dwarf2_addr (gdbarch, lowpc +
>> baseaddr)
>> +                      - baseaddr);
>>               SET_FIELD_PHYSADDR (call_site->target, lowpc);
>>             }
>>         }
> 
> That makes sense.  This means that with my patch, the value stored in
> the target was relocated, by interpreted as unrelocated?

Yes.

> Does that mean
> that with your patch, that value ended up relocated twice?  Once here,
> and once in objfile_relocate1?

No, though it took me some debugging to realize why :)

There are two scenarios:
- read_call_site_scope is triggered with baseaddr == 0, so the
  addresses are unrelocated.
  Then call_site_relocate is triggered with non-zero baseaddr, and
  the addresses become relocated.
- read_call_site_scope is triggered with non-zero baseaddr, so the
  addresses are relocated.
  Then call_site_relocate is not triggered, so the addresses remain
  correct, and are not relocated twice.

Thanks,
- Tom