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

[Gabriel Dos Reis]

On Sun, Sep 2, 2012 at 1:41 PM, Georg-Johann Lay <address@hidden> wrote:
> Gabriel Dos Reis schrieb:
>>
>> On Sun, Sep 2, 2012 at 12:17 PM, Georg-Johann Lay <address@hidden> wrote:
>>>
>>> Gabriel Dos Reis schrieb:
>>>>
>>>> On Sun, Sep 2, 2012 at 8:56 AM, Georg-Johann Lay <address@hidden> wrote:
>>>>>
>>>>> Weddington, Eric schrieb:
>>>>>>>
>>>>>>> On Behalf Of Georg-Johann Lay
>>>>>>>
>>>>>>> for historical reasons, AVR-Libc implements functions that
>>>>>>> GCC expects to live in libgcc, namely float functions like
>>>>>>> __fixsfsi.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Yes, we definitely want to make sure all the above are working.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Joerg Wunsch and I have talked for years about the idea of
>>>>>> integrating libm into libc, so that way there was only one library
>>>>>> to deal with. Would this be a good point to do that as well?
>>>>>> Would that make all the linker flag stuff easier to deal with?
>>>>>
>>>>>
>>>>> If there are plans to integrate libm into libc then this should
>>>>> be done *before* GCC supports --with-avrlibc configure option.
>>>>>
>>>>> Otherwise, AVR-Libc would knock out itself making the linker throw
>>>>> a "cannot find -lm" or similar linker error which would make that
>>>>> configure option obsolete...
>>>>>
>>>>> The preferred way would be *not* to move libm to libc so
>>>>> that the library layout is stable and the configure option
>>>>> works across various versions of AVR-Libc, even older ones.
>>>>>
>>>>> The intersection between libgcc and AVR-Libc is stable and
>>>>> did not change often, if I see correctly.  Changing the layout
>>>>> just now might be not helpful; except in the case there is
>>>>> a dummy libm.a that prevents "cannot find -lm" link error.
>>>>
>>>>
>>>> How about just having the driver add -lm (unless specifically
>>>> instructed not to) systematically?
>>>
>>>
>>> Could you explain this?
>>>
>>> specs like LIBGCC_SPEC and LINK_GCC_C_SEQUENCE_SPEC work on the
>>> driver level.
>>>
>>> The fixed-point issue shows that -lm is not enough and some functions
>>> have to be removed from libgcc.a if the compiler is to be used with
>>> AVR-Libc so that a new configure option is needed no matter what in
>>> order to get best performance.
>>
>>
>> My point was manyfold:
>>    -- From the original message, the fact that users did not specify -lm
>>        should never be an issue.  In fact, users should never have to
>>        specify -lm.
>
>
> That'saccomplished by the proposed changes to LINK_GCC_C_SEQUENCE_SPEC
> and LIBGCC_SPEC.

Yes.

> And there are users that still prefer C over C++.

Definitely, but that has nothing to do with with specs, right?

>  Two reasons are the
> named address spaces and the native fixed point support of ISO/IEC 18037
> which won't be supported by C++ if I understand correctly.

I think we (briefly) discussed named address spaces here.  But I would
think all of this is completely orthogonal to the spec modification proposal.

> Besides that, g++ (or C++) is rude with progmem...

ditto.  Right?

>
>
>>    -- have the driver pass -lm before -lgcc.  This is internal to GCC.
>>        It should never be user problem.  Unless user says "please don't;
>>        I have my own ideas about this."  Then user takes full
>> responsability
>>        for the fallout.  This should fix the -flto problem.
>
>
> That's also fixed by the new specs,

Yes, exactly.

> but g++ has its own concept of how
> -l options are passed and processed, see PR28718 and the discussion.

Two things:
   1.  None of the people involved in that discussion is a C++ compiler
        and/or a libstdc++ maintainer.  You would need to add at least
        a libstdc++ maintainer to the discussion in order to have a
        satisfactory resolution.  If you did not mention it now, I would
        most likely know of it: the PR is/was classified as a driver.

   2.  Yes, indeed, libstdc++ is not built when g++ is built.  This goes back
        to a discussion we had here a while ago.  Also, I do not think it helps
        the issue to describe the situation as libm is user-supplied
or user-written.
        People will get confused and start arguing all kinds of things -- if my
        past experience with libstdc++ when it was in its early enfancy and had
        its own release schedule and was largely independent.

The issue is clearly a bug in GCC -- at least according to my understanding
of the report.  We need to have the following happen:

    a. Bring it to C++ maintainers (both compiler library implementors) directly
         on the list.  I would suggest address@hidden and main
address@hidden

    b. You guys need to assist us (libstdc++ maintainers) to set up a
reliable way to
         build a portion of the free standing part of libstdc++.  Last
time we discussed
         this, I got two different directions.  One from here, and one
from Benjamin.
         We need to standardize on the recommended way to build g++ for AVR.

> The backend does not even have a way to hook in because g++ is too
> dumb.

Please, expand on this because I do not understand what you meant.

>  The solution above only works because the intersection between
> libm and libgcc is empty with the patch.

Yes, and I think that is a good property.  Again see how we handle
similar problems
with libstdc++ proper and libsupc++.

> Similar for -flto: It makes a difference if the user specifies -lm or
> the -lm comes from a spec, cf lto's -plugin-opt=-pass-through=-l***

I remain of the opinion that users should not have to specify -lm.
If the compiler does not behave correctly without -lm, then that is
a bug in how we (implementors) communicate between the code
generators and the support runtime.

>
>
>>    -- The libgcc problems to me means that we have a "layering" problem
>>        to address at the libgcc level. Maybe we should have libmath-core
>>        for the core-math (actually conversions) functions that libgcc
>> assumes.
>
>
> The problem of the non-empty libgcc-libm intersection is solved by
> making the intersection empty.

Yes, that is a preferable solution if it can be deployed.

>  I don't think yet another libfoo is helpful here.

>  libfoo's symbol names would still use libgcc's internal
> names like __addsf3.
>
> Moving core functions, i.e. functions in libm that are not in math.h,
> to libgcc won't happen because the original authors are no more around.

Agreed.

> Did I miss something with the proposed changes to the specs and/or
> LIB2FUNCS_EXCLUDE?

I agree with the spec modification.  However, I find the need for a configure
option  dubious.

-- Gaby