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

[Georg-Johann Lay]

Weddington, Eric schrieb:
> > On Behalf Of Georg-Johann Lay
> >
> > Hi,
> >
> > 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?

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.


Johann