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

[Georg-Johann Lay]

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
> > > > __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
>
> 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 
> "--with-avrlibc" ?
>
> 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 
> generic name).

There are different ways how such a support library could cooperate
with GCC.

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.


Johann