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: Jeff Law <law at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 01 Dec 2014 14:16:11 -0700
- 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>
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?
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?
Jeff