> Here we always have the original symbol value. We can
"derelocate" the
> in-place value by subtracting the symbol value to recover the lost addend.
Is this useful for anything?
Only to recover the symbol+addend so as to check the reloc in common
with the ET_REL treatment.
> symbol value (and barf if it's SHN_UNDEF)--note that since
it's an ET_REL,
(non-ET_REL I assume)
> the st_value is the final value directly, not section-relative. If there
Yes, sorry about the typo/braino.
At this time, dwarflint gives an error if ET_REL file misses a
relocation, but does relocation even in non-ET_REL files, if they are
present. According to what you say, it should instead ignore relocation
sections in non-ET_REL files.
That would be fine, yes.
Now what about DW_OP_call_ref, and others that Dwarf3 document claims
to
be "relocatable in a relocatable object file, and relocated in an
executable or shared object"? These are basically the reason why I
never had any doubts that I should handle relocations in non-ET_REL files.
These are just like DW_FORM_ref_addr and all the offset_size header fields.
For them "relocated" means resolved as relative to the target section,
i.e. as if it had been an allocated section with sh_addr=0. In all normal
non-ET_REL files, you will not have any relocs for these either. Only with
--emit-relocs (or tool bugs) will there be reloc sections for any of the
nonallocated sections at all.
Alan Modra's advice (from Jan's email, ignoring relocs that
use normal
symbol table) seems reasonable to me.
Except for anomalies (that elflint should catch if it doesn't already),
this will be the same as ignoring SHT_REL/SHT_RELA sections that are not
themselves SHF_ALLOC.
Thanks,
Roland