Re: [Patch,avr] PR54461: Better AVR-Libc integration

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Sep 4, 2012 at 1:01 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
> Richard Guenther wrote:
>> Georg-Johann Lay wrote:
>>> Gabriel Dos Reis schrieb:
>>>> Georg-Johann Lay wrote:
>>>>> Gabriel Dos Reis schrieb:
>>>>>> Georg-Johann Lay wrote:
>>>>>>> Gabriel Dos Reis schrieb:
>>>>>>>> Georg-Johann Lay wrote:
>>>>>>>>> AVR-Libc comes with hand-optimized float support functions
>>>>>>>>> written in assembler.  These functions use the same naming
>>>>>>>>> conventions like libgcc.  There are situations where this
>>>>>>>>> name clashed lead to performance regression because the
>>>>>>>>> functions from libgcc are linked.  One example are the new
>>>>>>>>> fixed-point support that convert fixed-point to/from float and
>>>>>>>>> reference float/int conversion functions from within
>>>>>>>>> libgcc.
>>>>>>>>>
>>>>>>>>> The float implementation in libm.a have been discussed
>>>>>>>>> several times with the only result that it is very unlikely
>>>>>>>>> that the code will ever be integrated into libgcc because
>>>>>>>>> the original authors are no more around.  And is is much
>>>>>>>>> less work to add a new configure switch than to port and
>>>>>>>>> integrate the code, given there were no license issues. One
>>>>>>>>> point against such an extension was that such change to the
>>>>>>>>> compiler establishes a dependency between the compiler and
>>>>>>>>> AVR-Libc, but this decision has been made long ago by
>>>>>>>>> accepting code that actually should had been added to
>>>>>>>>> libgcc -- but was not for whatever reason.
>>>>>>>>>
>>>>>>>>> This patch removes that performance regressions by removing
>>>>>>>>> the doubly implemented functions from libgcc by means of a
>>>>>>>>> new configure option --with-avrlibc.
>>>>>>>>
>>>>>>>> as I stated yesterday, I do not understand why there needs to
>>>>>>>> be yet another configure option. The NATURAL libc for ARV
>>>>>>>> targets is ARV-libc.  We should not need a switch for that.
>>>>>>>
>>>>>>> There is also newlib that is used with avr-gcc.  I know this
>>>>>>> because some bugs are only triggered for newlib.  If there are
>>>>>>> users that report bugs if avr-gcc is build for newlib, I'd
>>>>>>> guess these users are actually interested in using newlib.
>>>>>>
>>>>>> I did not say there was no other libc library.  I said that the
>>>>>> *natural* libc appears to be AVR-libc.
>>>>>>
>>>>>> We don't configure GCC/g++ saying --with-libstdc++.
>>>>>
>>>>> That's a different story because these libraries support in-tree build
>>>>> just like newlib does.  This is not true for AVR-Libc which does not support
>>>>> in-tree builds.
>>>>>
>>>>> I agree that AVR-Libc is the most common libc implementation used
>>>>> with avr-gcc and is has many advantages over other libc implementation
>>>>> (except that it does not support in-tree builds).
>>>>
>>>> I think the "in-tree builds" thing is a red herring.
>>>
>>> I don't think so.  If there was an in-tree build gcc could detect
>>> itself whether or not AVR-Libc is present or not.  With the
>>> current setup the user has to specify that -- in whatever
>>> direction: that libc is there or that libc is not there depending
>>> on whatever is default.
>>
>> You can do a link check on whether -lc provides those functions
>> and skip those that overlap with libgcc.
>
> Can you explain this?  A typical build of avr tools goes like
>
> 1) configure, build and install binutils
> 2) configure, build and install the compiler
> 3) configure, build and install AVR-Libc
>
> so that in step 2 no checking is possible because there is no -lc yet.
> Or do you mean a check at run time (of the compiler)?

4) build and install the real compiler

at which time you have AVR-libc available.  AT least that's how you
"bootstrap" a glibc cross.

Richard.

>
> Johann
>
>