> > 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
