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

[Georg-Johann Lay]

Gabriel Dos Reis schrieb:
> 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.

That'saccomplished by the proposed changes to LINK_GCC_C_SEQUENCE_SPEC
and LIBGCC_SPEC.

And there are users that still prefer C over C++.  Two reasons are the
named address spaces and the native fixed point support of ISO/IEC 18037
which won't be supported by C++ if I understand correctly.
Besides that, g++ (or C++) is rude with progmem...

>    -- 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.

That's also fixed by the new specs, but g++ has its own concept of how
-l options are passed and processed, see PR28718 and the discussion.
The backend does not even have a way to hook in because g++ is too
dumb.  The solution above only works because the intersection between
libm and libgcc is empty with the patch.

Similar for -flto: It makes a difference if the user specifies -lm or
the -lm comes from a spec, cf lto's -plugin-opt=-pass-through=-l***

>    -- 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.

The problem of the non-empty libgcc-libm intersection is solved by
making the intersection empty.  I don't think yet another libfoo is
helpful here.  libfoo's symbol names would still use libgcc's internal
names like __addsf3.

Moving core functions, i.e. functions in libm that are not in math.h,
to libgcc won't happen because the original authors are no more around.

Did I miss something with the proposed changes to the specs and/or
LIB2FUNCS_EXCLUDE?

Johann