Problems with branch-to-arm-from-thumb for typeless symbol
Tue Mar 5 00:08:00 GMT 2013
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
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the Binutils