[PATCH v6 0/6] ARM: vdso gettimeofday using generic timer architecture

Ard Biesheuvel ard.biesheuvel at linaro.org
Thu Apr 24 08:25:06 PDT 2014


On 24 April 2014 17:15, Nathan Lynch <Nathan_Lynch at mentor.com> wrote:
> On 04/24/2014 02:37 AM, Ard Biesheuvel wrote:
>> On 23 April 2014 23:50, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
>>> On Tue, Apr 22, 2014 at 07:48:51PM -0500, Nathan Lynch wrote:
>>>> - Build vdso.so with -lgcc: calls to __lshrdi3, __divsi3 sometimes
>>>>   emitted (especially with -Os).  Override certain libgcc functions to
>>>>   prevent undefined symbols.
>>
>> After reading Russell's concerns below, I had a quick play with these
>> patches, and I noticed that the libgcc dependencies are actually only
>> present when compiling -Os. However, with normal optimization enabled
>> (which most people are using anyway), you don't need libgcc at all. So
>> why not override -O2 optimization for vdso.so, and be done with it?
>>
>> WIth -Os:
>>
>> Archive member included because of file (symbol)
>>
>> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/sf/libgcc.a(_divsi3.o)
>>                               arch/arm/kernel/vdso/vgettimeofday.o
>> (__aeabi_idiv)
>> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/sf/libgcc.a(_lshrdi3.o)
>>                               arch/arm/kernel/vdso/vgettimeofday.o
>> (__aeabi_llsr)
>>
>> Without CONFIG_OPTIMIZE_FOR_SIZE, no archive members are included at all.
>
> Thanks.  I had thought about forcing -O2 in the past but just wasn't
> confident that it would prevent calls to __divsi3 etc in all situations.
>  I mean, that's not really a documented or guaranteed behavior of -O2,
> is it?
>

No it is not, unfortunately. But I agree with Russell that pulling in
bits of libgcc.a into your vdso is a bad idea.
It would be interesting to find out why exactly these dependencies are
there, so you can work around them.
And if that is not an option, it would be preferable IMO to duplicate
__aeabi_idiv under vdso/ somewhere if you really depend on it.

> I've now built vdso.so with your suggested change with GCC 4.[4-8]
> without getting any unresolved symbols, so here's hoping this is a
> viable option.
>

-- 
Ard.



More information about the linux-arm-kernel mailing list