[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?
Mon, 27 Aug 2012 11:39:31 +0200
Thunderbird 18.104.22.168 (Windows/20100228)
David Brown schrieb:
On 26/08/12 17:33, Georg-Johann Lay wrote:
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. 
OK, since we currently have this situation, then making this new
configuration option work is going to be the best way to get full
benefits of the externally implemented functions (in avrlibc).
But here is a thought - why call the configuration option
Surely there are more ports of gcc in exactly the same situation. There
are many out-of-tree ports of gcc, and one of the reasons for that is
that some of their contributions don't have copyright assignments.
And there are many other potential situations where development of code
outside of libgcc would be easier, as well as cases when there might be
multiple implementations of code (such as "small but slow" or "fast but
big" floating point code).
Small vs. fast is a matter of multilib layout. Currently -Os is not
a multilib option in avr-gcc, i.e. -Os will not affect the multilib
selection. One way to enable -Os is --enable-target-optspace=yes but I
don't know if PR2222 is fixed today...
Changing multilib layout always raises issues with AVR-Libc because
it does not support in-tree builds, see issue #35407.
For all these cases, your patch to make it easier to allow an external
library to replace functions from libgcc could be very helpful, if it
were made slightly more generic (or at least, had a slightly more
There are different ways how such a support library could cooperate
One approach is that the library libfoo uses its own namespace like
libfoo_add_float and when the compiler needs a support functions it
emits a call to libfoo_add_float instead of as to __addsf3.
If I remember correctly, that was the approach taken for the gofast lib.
Every library might need it's own special adjustments, and in the case
of libgcc functionality it's very likely the support library is not
called "libm.a" and does not "override" symbols from libgcc.
Moreover AVR-Libc makes assumptions on the ABI, for example it assumes
that the compiler always has set -fno-short-double. That may change
in the future. It's just some lines to have 64-bit doubles and have
-fshort-doubles as new multilib option. This means that SF functions
can be thrown out of libgcc, but not the DF functions.
The name "--with-avrlibc" is not special, it is just descriptive for
what it is intended for. For each "--with-foo=bar" comfigure switch
the tools automatically set up a shell variable called "with_foo"
and sets it to "bar". In the respective target configuration of
config.whatever, just test on that with_foo and hook in makefile
snippets or whatever.
--with-avrlibc is similar to --with-newlib. The only reason
--with-newlib is not needed in general is that newlib supports
in-tree builds in GCC:
If you hook in a directory called "newlib" to the GCC source tree,
it automatically configures and builds and installs newlib together
with GCC, including the actual multilib layout.
Very nice that. But AVR-Libc does not support in-tree builds,
which is a bit uncomfortable if AVR-Libc needs to implement a new
multilib layout like the new msp8 multilibs from avr-gcc 4.7.