[Top][All Lists]

[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 12:55:58 -0500

On Sun, Sep 2, 2012 at 12:17 PM, Georg-Johann Lay <address@hidden> wrote:
> Gabriel Dos Reis schrieb:
>> 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.
>> How about just having the driver add -lm (unless specifically
>> instructed not to) systematically?
> Could you explain this?
> specs like LIBGCC_SPEC and LINK_GCC_C_SEQUENCE_SPEC work on the
> driver level.
> The fixed-point issue shows that -lm is not enough and some functions
> have to be removed from libgcc.a if the compiler is to be used with
> AVR-Libc so that a new configure option is needed no matter what in
> order to get best performance.

My point was manyfold:
   -- From the original message, the fact that users did not specify -lm
       should never be an issue.  In fact, users should never have to
       specify -lm.  We have at least 2 decades of practice under the
        belt in the libstdc++ land :-)

   -- have the driver pass -lm before -lgcc.  This is internal to GCC.
       It should never be user problem.  Unless user says "please don't;
       I have my own ideas about this."  Then user takes full responsability
       for the fallout.  This should fix the -flto problem.

   -- The libgcc problems to me means that we have a "layering" problem
       to address at the libgcc level. Maybe we should have libmath-core
       for the core-math (actually conversions) functions that libgcc assumes.
       In many ways, this looks like the libsupc++ stuff we have in
the libstdc++ land.

-- Gaby

reply via email to

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