avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-


From: Gabriel Dos Reis
Subject: Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-Libc cooperation?
Date: Sun, 2 Sep 2012 10:22:03 -0500

On Sun, Sep 2, 2012 at 8:56 AM, Georg-Johann Lay <address@hidden> wrote:
> Weddington, Eric schrieb:
>>>
>>> On Behalf Of Georg-Johann Lay
>>>
>>> for historical reasons, AVR-Libc implements functions that
>>> GCC expects to live in libgcc, namely float functions like
>>> __fixsfsi.
>>>
>>> Currently, avr-gcc is not configurable to accommodate that
>>> situation which leads to performance problems if the float
>>> support functions from libgcc are used.
>>>
>>> This happens at least in the following situations:
>>>
>>> * The user does not specify -lm.  -lm should only be needed
>>>    if function from math.h are used, not for language core
>>>    features like int i = (int) float.
>>>
>>> * The application is LTO compiled, i.e. linked with -flto.
>>>    The plugin machinery passes lgcc -lc lgcc through to the
>>>    linker by means of -plugin-opt=-pass-through=-lgcc etc.
>>>    so that -lgcc is linked prior to -lm.
>>>
>>> * The user uses fixed <-> float conversion routines from
>>>    libgcc.  These routines refer float functions, and the linker
>>>    resolves these function in libgcc if they are there.
>>>
>>> * avr-g++ is used as linker driver.
>>
>>
>> Yes, we definitely want to make sure all the above are working.
>>
>>>
>>> In order to fix all of these cases, at least two changes
>>> are needed in the compiler.
>>>
>>> 1) Remove respective functions from libgcc
>>>
>>> 2) libm.a is not a "math library", it is a "libgcc supplement".
>>>     Thus, -lm has to be treated like libgcc.
>>
>>
>> Joerg Wunsch and I have talked for years about the idea of
>> integrating libm into libc, so that way there was only one library
>> to deal with. Would this be a good point to do that as well?
>> Would that make all the linker flag stuff easier to deal with?
>
>
> If there are plans to integrate libm into libc then this should
> be done *before* GCC supports --with-avrlibc configure option.
>
> Otherwise, AVR-Libc would knock out itself making the linker throw
> a "cannot find -lm" or similar linker error which would make that
> configure option obsolete...
>
> The preferred way would be *not* to move libm to libc so
> that the library layout is stable and the configure option
> works across various versions of AVR-Libc, even older ones.
>
> The intersection between libgcc and AVR-Libc is stable and
> did not change often, if I see correctly.  Changing the layout
> just now might be not helpful; except in the case there is
> a dummy libm.a that prevents "cannot find -lm" link error.
>
> Johann

How about just having the driver add -lm (unless specifically
instructed not to) systematically?

-- Gaby



reply via email to

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