This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, MPX wrappers 1/3] Add MPX wrappers library
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Dec 2014 17:28:57 +0300
- Subject: Re: [PATCH, MPX wrappers 1/3] Add MPX wrappers library
- Authentication-results: sourceware.org; auth=none
- References: <20141114172601 dot GA20207 at msticlxl57 dot ims dot intel dot com> <5466FC6A dot 3080806 at redhat dot com> <20141118164817 dot GC47331 at msticlxl57 dot ims dot intel dot com> <546BB6E9 dot 3020406 at redhat dot com> <20141121154630 dot GC30483 at msticlxl57 dot ims dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1411212327480 dot 32250 at digraph dot polyomino dot org dot uk> <20141124140645 dot GB9490 at msticlxl57 dot ims dot intel dot com> <547CDA9B dot 8080500 at redhat dot com>
2014-12-02 0:16 GMT+03:00 Jeff Law <law@redhat.com>:
> On 11/24/14 07:06, Ilya Enkovich wrote:
>>>
>>> Normally GCC target libraries assigned to the FSF would use GPL+exception
>>> rather than LGPL (especially if the library might be linked in
>>> statically), to keep predictable what requirements are imposed by linking
>>> your program with GCC. libquadmath is an exception because it contains
>>> LGPL code not assigned to the FSF.
>>
>>
>> I'm OK to put it under GPL+exception.
>
> Well, if copyright is assigned to the FSF in the usual manner, then the FSF
> can relicense as appropriate.
>
>
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 8f5d76c..283c632 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -1043,6 +1043,9 @@ Instrument only functions marked with bnd_instrument
>> attribute.
>> static-libmpx
>> Driver
>>
>> +static-libmpxwrappers
>> +Driver
>
> Isn't something more needed here?
>
>> +
>> fcilkplus
>> C ObjC C++ ObjC++ LTO Report Var(flag_cilkplus) Init(0)
>> Enable Cilk Plus
>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>> index 75e5767..aa8c9a3 100644
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -828,9 +828,23 @@ proper position among the other output files. */
>> #endif
>> #endif
>>
>> +#ifndef LIBMPXWRAPPERS_SPEC
>> +#if defined(HAVE_LD_STATIC_DYNAMIC)
>> +#define LIBMPXWRAPPERS_SPEC "\
>> +%{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers:\
>> + %{static:-lmpxwrappers}\
>> + %{!static:%{static-libmpxwrappers:" LD_STATIC_OPTION "
>> --whole-archive}\
>> + -lmpxwrappers %{static-libmpxwrappers:--no-whole-archive "\
>> + LD_DYNAMIC_OPTION "}}}}}"
>> +#else
>> +#define LIBMPXWRAPPERS_SPEC "\
>> +%{mmpx:%{fcheck-pointer-bounds:{!fno-chkp-use-wrappers:-lmpxwrappers}}}"
>> +#endif
>> +#endif
>
> My concern here is we're embedding target specific bits (existence of -mmpx
> flag) into gcc.c. Shouldn't this be buried in the x86 backend which is
> allowed to know about the specifics?
>
>
>> +
>> #ifndef MPX_SPEC
>> #define MPX_SPEC "\
>> -%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC "}}"
>> +%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}"
>> #endif
>
> Ugh. Somehow I missed that MPX_SPEC was in gcc.c along with the uses of
> LIBMPX_SPEC. Aren't all these target specific and thus belong in the x86
> specific files?
Is config/i386/linux-common.h is a proper place for these specs then?
>
> Presumably all this is dependent on the libmpx bits being accepted, right
> (and yes, I realize that I've got a TODO on that :-)
>
> And presumably the wrappers aren't really specific to MPX, they're a
> mechanism for you to get more information to the checker, regardless of
> whether it's MPX based on a pure software solution, right?
Right. Wrappers code doesn't use anything specific to MPX. In case of
pure software solution we should be able to compile and use this
library without changes (except compilation flags). But in case pure
software solution exists MPX option should still be available and we
should have two builds for this library.
Ilya
>
> Jeff