Re: farcall-section test

[Richard Earnshaw <rearnsha at arm dot com>]

On Tue, 2009-02-24 at 09:15 -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 24, 2009 at 01:53:43PM +0000, Paul Brook wrote:
> > Hmm, I guess so.
> > 
> > Actually, reading the AAELF again, it says "T is 1 if the target symbol has 
> > type STT_FUNC and the symbol addresses a Thumb instruction". i.e. 
> > non-function symbols are treated as ARM.
> > 
> > Also relevant is:
> > "A linker may use a veneer [...] if [...] The target symbol has type 
> > STT_FUNC."
> > 
> > i.e. an error is the correct behavior here. IMO this makes sense: If a symbol 
> > isn't marked as a function, we can't really be sure it's actually a public 
> > entry point, and probably can't safely clobber r12.
> 
> I don't think it means exactly that.  Here's the full quote:
> 
>  A linker may use a veneer (a sequence of instructions) to effect the
>  relocated branch if any of the following conditions apply:
> 
>      The target symbol has type STT_FUNC
> 
>      The target symbol and relocated place are in separate input
>      sections to the linker
> 
>  In all other cases a linker shall diagnose an error if relocation
>  cannot be effected without a veneer.
> 
> Note "any".  Sounds like we should be able to do this - and hot/cold
> partitioning should know that the branch might corrupt IP.  On the
> other hand, I can't find another way to interpret the quote about
> setting "T"...
> 
> Unrelated: do we implement this one?
> 
>  On platforms that do not support dynamic pre-emption of symbols an
>  unresolved weak reference to a symbol relocated by R_ARM_CALL shall be
>  treated as a jump to the next instruction (the call becomes a
>  no-op).

This is an area that is fraught with difficulties, and there are lots of
'may's and not many 'must's.

A linker is never required to use veneers if it can reasonably find a
way of generating correct code without one.  However, object producers
must assume that a linker will insert a veneer at every location where
one is permitted.  A linker may not insert a veneer that alters any
register, stack or other machine state (including writing below the
stack -- the stack pointer may not even be valid!) at any point where
such permission is explicitly granted by the ABI.

On the issue of calling to a label that is not marked as STT_FUNC, you
are definitely in the QOI space -- a linker is not required to handle
this, but it can if it is reasonably confident that it is doing the
right thing.  Using mapping symbols as a way of determining the right
thing is, I think, an acceptable approach; but there's nothing in the
ABI specs that requires it for this case.

Linkers *are* required to handle the case where the function is marked
STT_FUNC and to believe that the encoding is correct; however, a linker
might also want to validate that the mapping symbol for the targetted
address matches the type of the jump being generated.  That's fine for
the simple case, but what if there is an offset from the address in an
addend and the mapping changes between the symbol and the final
destination?  The ABI requires the symbol to be believed here, but it
might want to issue a warning...

R.