[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: Georg-Johann Lay
Subject: Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-Libc cooperation?
Date: Tue, 28 Aug 2012 12:17:15 +0200
User-agent: Thunderbird (Windows/20100228)

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

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?

The compiler has to be extended for a better AVR-Libc
integration, anyway, as the fixed <-> float conversions shows.

Whether the routines reside in lm or lc makes no difference
and there's still the problem that libgcc symbols are used.

Compared to the effort of assimilating libm into libc,
it's much easier to write one -lm in one gcc spec.  Problems
would only arise if -lm would be removed one day; then you'd
need --with-avrllibc=1.9.0 or so.  I don't thinks that's
desirable, a simple on/off yes/no interface should be enough.

--start/end-group around -lgcc -lc is still needed instead of the
current -lgcc -lc -lgcc, in particular because libc might need
stuff from libgcc and libgcc might need functions from libc again.

This occurs if libc uses fixed <-> float conversion.  That uses the
conversion from libgcc which then requires the int <-> float routines
from libc.  Thus, the sequence is at least -lgcc -lc -lgcc -lc, and
consequently --start/end-group is more clear.


reply via email to

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