This is the mail archive of the
mailing list for the binutils project.
Re: [RFC PATCH] Avoid emitting TEXTREL marker for R_ARM_NONE relocs.
- From: Roland McGrath <mcgrathr at google dot com>
- To: Roland McGrath <mcgrathr at google dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 13 Mar 2014 10:16:48 -0700
- Subject: Re: [RFC PATCH] Avoid emitting TEXTREL marker for R_ARM_NONE relocs.
- Authentication-results: sourceware.org; auth=none
- References: <CAB=4xhr7yOFiFByCMieKYoNsGe3ZaMb5cj0GL4K3CFUTJf6fTw at mail dot gmail dot com> <20140312225242 dot GX26922 at bubble dot grove dot modra dot org>
On Wed, Mar 12, 2014 at 3:52 PM, Alan Modra <firstname.lastname@example.org> 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.