Re: [PATCH, RFC, RFT] ARM relocation fixes

[Leif Lindholm]

On Tue, Dec 03, 2013 at 10:31:13AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> >> I meant that you can use conditions with bl but not blx. So if we have a
> >> reloc on ARM bl.e targetting Thumb then we have to add veneers. Since we
> >> have only small number of interworking calls it's probably easier to
> >> always add veneers on interworking relative relocations rather than
> >> having micro-optimisation and get some minor case wrong.
> > 
> > OK, but the only place we could ever have a problem with this would
> > be if we had asm in the kernel _explicitly_ done as .thumb.
> > Which we don't. We explicitly moved away from that in order to have
> > support for pre-v7 processors.
> > 
> We also call C code from asm. One such instance (for division
> instructions) caused the problem
> > All modules will have full 32-bit external references, so will not
> > use these instructions anyway. Any internal references within modules
> > will be linked with LD, which will fix this up automatically.
> > 
> In my small test I compiled:
> extern void g(void);
> 
> void f (int x)
> {
>   if (!x)
>     g();
> }
> And got following assembly with -Os:
> 
>    0: e3500000        cmp     r0, #0
>    4: e92d4008        push    {r3, lr}
>    8: 0bfffffe        bleq    0 <g>
>                       8: R_ARM_JUMP24 g
>    c: e8bd4008        pop     {r3, lr}
>   10: e12fff1e        bx      lr
> 
> If g is a function in thumb kernel or thumb module then you need a veneer.

Ok, you got me. Didn't consider -Os.
But the second case would still be auto-added by the linker.

But what is the objection to -mlong-calls?

My armv7 kernel ends up only slightly larger with this option (57272
bytes vs. 57088) - 184 bytes, from which 12 bytes per veneer can be
subtracted. And the overall arm-efi directory is smaller (10031244 vs.
10254924). For just the *.mod too (1229498 vs. 1234034).

When compiling for For ARM (A32) (i.e. armv6), there is no difference
in kernel size, but modules do grow 1.8% from 1477726 to 1503986.
But is it really worth adding complexity to grub-mkimage for a small
benefit to legacy platforms only? Could we instead add an arm_cflags
with -mlong-calls for kernel in Makefile.core.def?

/
    Leif