[PATCH] RTEMS: Add GCC Runtime Library Exception
Jeff Law
law@redhat.com
Fri Jan 12 22:57:00 GMT 2018
On 12/21/2017 11:59 PM, Sebastian Huber wrote:
> On 21/12/17 05:58, Jeff Law wrote:
>> On 08/22/2017 11:15 PM, Sebastian Huber wrote:
>>> Hello Jeff,
>>>
>>> On 03/08/17 07:11, Sebastian Huber wrote:
>>>> On 02/08/17 21:30, Jeff Law wrote:
>>>>
>>>>> On 07/24/2017 12:03 AM, Sebastian Huber wrote:
>>>>>> gcc/
>>>>>>
>>>>>> Â Â Â Â PR libgcc/61152
>>>>>> Â Â Â Â * aarch64/rtems.h: Add GCC Runtime Library Exception. Format
>>>>>> Â Â Â Â changes.
>>>>>> Â Â Â Â * arm/rtems.h: Likewise.
>>>>>> Â Â Â Â * bfin/rtems.h: Likewise.
>>>>>> Â Â Â Â * i386/rtemself.h: Likewise.
>>>>>> Â Â Â Â * lm32/rtems.h: Likewise.
>>>>>> Â Â Â Â * m32c/rtems.h: Likewise.
>>>>>> Â Â Â Â * m68k/rtemself.h: Likewise.
>>>>>> Â Â Â Â * microblaze/rtems.h: Likewise.
>>>>>> Â Â Â Â * mips/rtems.h: Likewise.
>>>>>> Â Â Â Â * moxie/rtems.h: Likewise.
>>>>>> Â Â Â Â * nios2/rtems.h: Likewise.
>>>>>> Â Â Â Â * powerpcspe/rtems.h: Likewise.
>>>>>> Â Â Â Â * rs6000/rtems.h: Likewise.
>>>>>> Â Â Â Â * rtems.h: Likewise.
>>>>>> Â Â Â Â * sh/rtems.h: Likewise.
>>>>>> Â Â Â Â * sh/rtemself.h: Likewise.
>>>>>> Â Â Â Â * sparc/rtemself.h: Likewise.
>>>>> This seems horribly wrong. Did anyone ack this change? I'm fully
>>>>> supportive of target maintainers taking care of their areas, but
>>>>> licensing stuff probably should get explicitly ack'd.
>>>>>
>>>>> I just reviewed all the rtems config files and I don't see anything in
>>>>> any of them that deserves a runtime exception with the possible
>>>>> exception of rs6000/rtems.h.
>>>>>
>>>>> Seriously. Redefining the CPP builtins? LINK_SPEC? #undefs? Those
>>>>> are not things we should be granting an exception for.
>>>>>
>>>>> The one that looks marginal to me would be rs6000/rtems.h and its
>>>>> definition of CRT_CALL_STATIC_FUNCTION.
>>>> I asked on the mailing list:
>>>>
>>>> https://gcc.gnu.org/ml/gcc/2017-07/msg00171.html
>>>>
>>>> Jakub Jelinek said that for header files included by libgcc it is
>>>> important whether they have the runtime exception or not:
>>>>
>>>> https://gcc.gnu.org/ml/gcc/2017-07/msg00176.html
>>>>
>>>> There is also this PR61152 from 2014
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
>>>>
>>>> which adds the runtime exception to a couple of gcc/ subdirectory
>>>> files (including some RTEMS files). So, I had no explicit acknowledge,
>>>> but my impression was that I did simply fix some left over files.
>>>>
>>>> If you don't add the runtime exception to files included by libgcc,
>>>> then the user of GCC must check that these files contain no content
>>>> that deserves a copyright. Is this really user friendly?
>>>>
>>> What should I do now? It would be nice to have a general guideline on
>>> how to deal with header files used by libgcc.
>> You have to look at each header and determine how the contents are used
>> and whether or not those uses are of a nature that requires an exception.
>>
>> So, yes it's important to get the exception in there when it's needed.
>> But that doesn't mean we just drop the exception into every file that's
>> included by something in libgcc. We are stewards of the GCC sources for
>> the FSF and we have to be very careful when it comes to changing the
>> licensing on any code.
>>
>> WRT 61152.  That doesn't mean splatting the runtime exception into
>> those files is/was the correct thing to do. Again, one has to look at
>> it on a file by file basis. I have not looked at those changes in
>> detail to know if they really need the license exception or not.
>>
>> The FSF has been very clear through the decades that linking against
>> libgcc should not drag the user's code under the terms of the GPL. So
>> all users have to do is extend a degree of trust. When files have
>> actually needed a license change we've taken care of it and always will.
>>
>>
>> I'm not going to demand you revert the change, but let's please get an
>> explicit ack before changing the licensing terms in the future.
>
> Ok, thanks for the clarification. I will be more careful in the future.
>
> What is the status of this PR
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
>
> now? Can it be closed with a notice that this must be decided file by file?
Seems reasonable with a note that it needs to be decided file by file.
jeff
More information about the Gcc-patches
mailing list