[PATCH, ARM] Don't pass incorrect pointer in arm_build_one_stub

Julian Brown julian@codesourcery.com
Thu Jul 2 14:05:00 GMT 2015


Hi!

On Thu, 2 Jul 2015 18:25:09 +0800
Thomas Preud'homme <thomas.preudhomme@arm.com> wrote:

> > From: Julian Brown [mailto:julian@codesourcery.com]
> > 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.)

Julian



More information about the Binutils mailing list