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