[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-
Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-Libc cooperation?
Sun, 02 Sep 2012 20:41:43 +0200
Thunderbird 188.8.131.52 (Windows/20100228)
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
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
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
That'saccomplished by the proposed changes to LINK_GCC_C_SEQUENCE_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