Re: ARM/Thumb long calls stubs

[Nick Clifton]

Hi,

> But how can I know in advance what functions should be made
> "long-calls"? I don't want compiler to use BX instead of BL
> everywhere.

In general you can't know.  In practice you can probably tell from the
nature of your application.  If the reason for the large distances is
because there is a section of code in "high" memory space and the rest
of the code is in "low" memory space, then you just add the long call
attribute to the prototypes for the externally visible functions that
must be called from either region.

If you have a truly humongous application such that it actually
occupies more than 4M of address space, then you could find out by
experimentation (which function calls fail) or by examining a linker map
(produced with the -Map switch).

 
> With -mlong-calls I can not control what code compiler uses to call
> thumb to arm _stub_.

True.

> LD generates only one stub for ARM_func. That only stub may be not
> accessible from some parts of thumb code. 
> 
> So how can this be done without linker support?

To workaround the problem you could provide ARM-to-ARM or
THUMB-to-THUMB long call entry points.  eg:

  .... compile in ARM mode ...

  ARM_func (void) {}

  .... compile in Thumb mode ...

  THUMB_long_call_to_ARM_func (void) { ARM_func (); }

  ... compile separately in Thumb mode and ...
  ... place in memory a long way away ...

  extern void THUMB_long_call_to_ARM_func (void) __attribute__((long_call));
  Thumb_func (void) { THUMB_long_call_to_ARM_func (); }

> It would be nice for the linker to add long-calls stubs instead. Is
> that possible?

Anything is possible, so yes it could be done.

> It doesn't. It generates wrong offsets instead and hence broken
> code.

Please could you submit a simple test case then ?

Cheers
        Nick