This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Another relocation oddness
- From: Roland McGrath <roland at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 20 Apr 2009 12:30:00 -0700
- Subject: Re: Another relocation oddness
> > 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