Re: [RFC PATCH] Avoid emitting TEXTREL marker for R_ARM_NONE relocs.

[Roland McGrath <mcgrathr at google dot com>]

On Wed, Mar 12, 2014 at 3:52 PM, Alan Modra <amodra@gmail.com> wrote:
> One case that springs to mind is .eh_frame editing, which happens
> after dynamic relocations have been allocated.  If you require dynamic
> relocations in .eh_frame CIEs (say due to using absolute encoding for
> some field) and CIEs are merged, then you can end up needing fewer
> dynamic relocations than allocated.

I was going to say this couldn't be my case because I don't have .eh_frame,
being ARM.  But in fact I do have some .eh_frame content (as well as
.ARM.exidx), and I'll have to figure out where that came from.

> Do you know where the R_ARM_NONE dynamic reloc came from?  Tip:
> -z nocombreloc helps in answering that question.

Thanks for the tip.  That just told me they (there are two) are in
.rel.text, and they're the only relocs that end up there.  So still
not telling me very much.  I'll keep investigating.

Probably I'll find these and make them go away and so the DT_TEXTREL mark
for me was just fallout of a different problem (and I'm glad that it made
me notice the underlying problem).

But I maintain it's a bug that DT_TEXTREL can ever be set when there are no
actual dynamic relocs in read-only segments in the final image.  (I still
have a hard time accepting it's not a bug to ever emit R_ARM_NONE instead
of just making the reloc section shorter, even if that means leaving some
useless padding after it because of layout order.  But I've long since
decided to let that one go.)

> No, this is wrong.  The code you're touching here deals with
> relocations for local symbols, elf32_arm_readonly_dynrelocs scans
> global symbols.

I see.


Thanks,
Roland