Re: Problems with branch-to-arm-from-thumb for typeless symbol

[Mike Frysinger <vapier at gentoo dot org>]

On Sunday 03 March 2013 22:40:27 Hans-Peter Nilsson wrote:
> I did a little digging.  You know all this, but for the record,
> AAELF (ELF for the ARM Architecture; the BPAPI for ARM in ELF
> parlance) as per
> <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.p
> df> says in "4.5.2 Symbol Types": "All code symbols exported from an
> object file (symbols with binding STB_GLOBAL) shall have type
> STT_FUNC", but I'm not sure whether that implies there's a bug
> in the assembler or if it just means to restrict where AAELF
> applies.  Maybe best leave current behavior as-is there.

i can't see how this would be a bug in the assembler.  it has no idea what 
symbols represent until you explicitly give them a type.  you could argue that 
any symbol in a @progbits section should default to STT_FUNC, but i think we 
can agree that making that sort of change would be even worse for backwards 
compatibility.

> AAELF
> seems to open up for the existence of untyped code symbols when
> it later states "The linker is only required to provide
> interworking support for symbols of type STT_FUNC (interworking
> for untyped symbols must be encoded directly in the object
> file)."  Note "only required to", not "required only to",
> leaving whether it also does it for untyped symbols is optional.
> (Regarding splitting hairs, there's a "must" there, but as
> noted, it already accepted an exception to a "shall".)
> 
> The issue would not have arisen if behavior had been consistent
> across versions.  Indeed, a mode-changing stub *used* to be
> generated for the test-case; it was changed in binutils-1.21
> (apparently CVS 1.261 of elf32-arm.c), but the behavioral change
> seems to have been unintended; it wasn't mentioned as such in
> the patch, the post or covered by the test-suite.  This would
> IMHO have been a newsworthy item.  See
> <http://sourceware.org/ml/binutils/2011-03/msg00055.html>, where
> apparently this change was introduced (arm_type_of_stub as
> below) when doing a rewrite as part of ARM support for IFUNC,
> but the specific behavioral change is not noted in that thread,
> references or test-suite changes, while being a newsworthy
> change, silently causing such existing code to "fail".

sure, updating NEWS would be good.  i would highlight:
 - the change has been live for 2 years at this point
 - the number of impacted projects is low
 - the fix in the code is trivial and backwards compatible
 - the linker is conforming to the spec

> Also, the current linker behavior is inconsistent; if the branch
> is out-of-range, a mode-changing-stub *is* generated.  Note the
> lack of symbol type specification for the global symbol
> func_to_branch_to in e.g. ld/testsuite/ld-arm/fix-arm1176.s that
> is used to trigger a stub or change to blx!

certainly consistency is good.  feel like fixing that too ? :)

> > The assumption is that if you call an untyped symbol the code knows what
> > it is doing and that special processing for interworking is not
> > required.  Furthermore, the guarantee that IP (r12) is free as an
> > interworking register is not available for untyped symbol interfaces.
> 
> I know I stated my question generally, but the issue is just
> with stubs *from thumb to arm* so IIUC clobbering r12/ip isn't
> an issue.
> 
> I'm suggesting we change back behavior to always generate
> mode-changing stubs from thumb to arm as per below.  Either way,
> consistency is expected and I can't see how this could cause
> harm for users, in contrast to the current situation.
> 
> Checked arm-linux-eabi and arm-eabi.
> 
> Ok to commit?

at the very least, this should issue a warning imo.  the behavior this relies 
on is non-portable.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.