[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH, RFC, RFT] ARM relocation fixes
Date: Tue, 03 Dec 2013 13:00:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 03.12.2013 12:16, Leif Lindholm wrote:
> 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.
LD in -r mode doesn't always resolve all relocs
> But what is the objection to -mlong-calls?
Originally it was from my experiments with clang. It doesn't accept
-mlong-calls. But clang isn't enough of motivation for this complexity,
far from it. My motivation is to have a robust dynamic linker with
interwork possibilities, that we won't have to rewrite when new compiler
changes behaviour or if we decide to decrease the requirement to armv4.
I think, I'll make build system add -mlong-calls if it's supported by
> 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.
I'm confused by numbers: I don't see which ones relate to which configs
(long-calls/no-long-calls A32/T16/T32)
> 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
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]