[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: Sun, 26 Aug 2012 17:33:22 +0200
User-agent: Thunderbird (Windows/20100228)

David Brown wrote:
Georg-Johann Lay wrote:

for historical reasons, AVR-Libc implements functions that
GCC expects to live in libgcc, namely float functions like

Would it not be a better idea to move the functions from AVR-Libc
into libgcc? Or are there complicating issues, such as copyright assignments, that make that a harder job?



Yes, that's the issue.

The original authors put their code in AVR-Libc, presumably because
it was easier to get the code in there than to get it into GCC.

To get it into GCC, you have to sign a copyright assignment and
provide proper patches that passed tests(uite), comply to coding
rules, come with ChangeLogs, documentations etc.  It's then up
to the maintainer to push the code upstream, but he won't fix
bugs or typos or coding rules or whatever.

For AVR-Libc it's enough to outline a change, at least that was
my impression from the improved [u]ltoa functions from SVN 2298.

Besides that, even *if* the original authors released their code
under an additional license *and* filed FSF copyright assignments,
someone would have to actually carry the code migration.

From the number of people that contribute to avr-gcc, this is
simply not realistic.  A potential move has been discussed too
often before without any results -- except that it's extremely
unlikely anybody will integrate it into libgcc.

Adding a new configure option to gcc is much less work and
straight forward.  All that has to be done is to review the excludes
list and make sure that not too much or to less is removed.
And run regression tests, of course.

The objection against such a change was that it introduces a
dependency between avr-gcc and AVR-Libc, but this dependency
was introduced long ago, namely when it was decided to re-implement
functions that live in libgcc once more in AVR-Libc and use
reserved names like __addsf3 together with an "override" hack and
implications on how GCC orders -lgcc, -lm, -lc, or how LTO works.

In addition to the proposed new t-avrlibc Makefile snippets,
there could be defines for, cf. [1]




[1] http://gcc.gnu.org/onlinedocs/gccint/Library-Calls.html

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.

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.

avr.h currently has:

#define LIBGCC_SPEC "\
%{!mmcu=attiny15:%{!mmcu=attiny28: -lgcc }}}}}"

LINK_GCC_C_SEQUENCE_SPEC is defined and defaults to
"%G %L %G"

Together with 1) which is already contained in the proposed
patch for libgcc, a reasonable spec layout would be

#define LIBGCC_SPEC "\
%{!mmcu=attiny15:%{!mmcu=attiny28: -lgcc -lm }}}}}"

"--start-group %G %L --end-group"

Could a AVR-Libc maintainer test this setup?

To test the attached patch, use avr-gcc from trunk
SVN 190644 or newer and configure --with-avrlibc=yes

To test the new specs, you can

$ avr-gcc -dumpspecs > my.specs

and then

$ avr-gcc -specs my.specs ...

The specs in question are libgcc and link_gcc_c_sequence.

This means that the option makes avr-gcc assume that
AVR-Libc comes with a specific layout: -lm is available
and comes with libgcc-like support and fills out the gaps
introduced by LIB2FUNCS_EXCLUDE from t-avrlibc.

Just like the t-avrlibc in libgcc, there would be a t-avrlibc
Makefile snip in gcc that takes care of the specs and
(re)defines them if configured for AVR-Libc cooperation.

Moreover, it must be ensured that no function causes ABI
clashes. For example, libgcc brings ffs with optimized ABI
similar to __divmodxx4: The compiler knows what registers
are clobbered and what are not, and/or it may pass values
in non-ABI registers.

Functions in question are, in all available modes:
ffs, ctz, clz, bswap, popcount, parity

BTW: The last point is an issue already present in the current
releases and not related to a new configure option.



reply via email to

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