This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, ARM] Don't pass incorrect pointer in arm_build_one_stub
- From: Julian Brown <julian at codesourcery dot com>
- To: Thomas Preud'homme <thomas dot preudhomme at arm dot com>
- Cc: <binutils at sourceware dot org>, Doug Kwan <dougkwan at google dot com>
- Date: Thu, 2 Jul 2015 15:04:27 +0100
- Subject: Re: [PATCH, ARM] Don't pass incorrect pointer in arm_build_one_stub
- Authentication-results: sourceware.org; auth=none
- References: <20090710141535 dot 6be29db4 at rex dot config> <003501d0b4b1$6a467d80$3ed37880$ at arm dot com>
On Thu, 2 Jul 2015 18:25:09 +0800
Thomas Preud'homme <email@example.com> wrote:
> > From: Julian Brown [mailto:firstname.lastname@example.org]
> > Sent: Friday, July 10, 2009 9:16 PM
> > This patch passes the hash for a symbol from which a stub entry was
> > derived, not the hash for the stub entry itself, to
> > elf32_arm_final_link_relocate. This fixes a potential incorrect code
> > generation issue (not seen on mainline so far, AFAIK). In practice,
> > there will be no symbols for the stubs in question, so the value
> > passed should always be NULL (though a non-NULL value would be
> > passed prior to
> > this patch, which could cause elf32_arm_final_link_relocate to get
> > confused).
> It seems to me that this forbids veneer for global symbols
> (stub_entry->h non NULL) with relocations. Why is this safe? I'm
> hitting this assert on a patch I'm working on and I don't understand
> what would go wrong with a non NULL h.
I've unfortunately completely lost context on this patch now, and I
couldn't find anything useful in Mentor's private patch tracker about it
either. I may have been simply mistaken, and/or failed to take some
particular case into account.
(Maybe Doug can remember something? The original thread mentions he
noticed the original problem the patch was meant to solve initially.)