This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] RTEMS: Add GCC Runtime Library Exception


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?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]