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

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

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
compiler.
> 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]