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

[Georg-Johann Lay]

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
> > __fixsfsi.
>
> 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?
>
> mvh.,
>
> David

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]

* TARGET_C99_FUNCTIONS
* TARGET_HAS_SINCOS

Thoughts?


Johann

[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=at90s1*:%{!mmcu=attiny11:%{!mmcu=attiny12:\
> > %{!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=at90s1*:%{!mmcu=attiny11:%{!mmcu=attiny12:\
> > %{!mmcu=attiny15:%{!mmcu=attiny28: -lgcc -lm }}}}}"
> >
> > #undef LINK_GCC_C_SEQUENCE_SPEC
> > #define LINK_GCC_C_SEQUENCE_SPEC \
> > "--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.
> >
> > Thanks,
> >
> > Johann