| Message ID | 20150526091327.GI47912@msticlxl57.ims.intel.com |
|---|---|
| State | New |
| Headers | show |
On 05/26/2015 03:13 AM, Ilya Enkovich wrote: > On 06 Apr 09:28, Jeff Law wrote: >> On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >>>> >>>> To tell the truth, I can't figure out what this means from a user >>>> perspective. How does a user know whether the linker option is >>>> being ignored, or if they have a new enough linker? If the linker >>>> available at configuration time doesn't support the option, does >>>> that mean the option will never be passed and users will never know >>>> that there are gaping holes in the pointer bounds checking? >>>> >>>> My suggestion would be to pass the option unconditionally and make >>>> the documentation say something like >>> >>> This option was rejected. >> Right. There really isn't a good option here because we don't have >> the infrastructure to query the linker's capabilities at link time. >> >> Though I do wonder if we could issue a warning in the case where the >> configure test indicated -z bndplt was not supported. >> >> It'd obviously mean a link warning every time an end user tried to >> use that toolchain to create a DSO or executable with MPX >> protection. But that may be better than silently leaving some code >> unprotected. >> >> >> Jeff >> > > Hi, > > Here is a patch to add a note in case we build dynamic MPX codes and don't pass '-z bndplt'. Does it look OK? > > Thanks, > Ilya > -- > gcc/ > > 2015-05-26 Ilya Enkovich <enkovich.gnu@gmail.com> > > * config/i386/linux-common.h (MPX_SPEC): Add link > warning. > > libmpx/ > > 2015-05-26 Ilya Enkovich <enkovich.gnu@gmail.com> > > * configure.ac: Add link_mpx_warning. > * libmpx.spec.in: Likewise. > * configure: Regenerate. Is there a way to do this outside of the specs mechanism? If done in the specs, are these warnings translated for locales? Jeff
2015-05-27 18:19 GMT+03:00 Jeff Law <law@redhat.com>: > On 05/26/2015 03:13 AM, Ilya Enkovich wrote: >> >> On 06 Apr 09:28, Jeff Law wrote: >>> >>> On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >>>>> >>>>> >>>>> To tell the truth, I can't figure out what this means from a user >>>>> perspective. How does a user know whether the linker option is >>>>> being ignored, or if they have a new enough linker? If the linker >>>>> available at configuration time doesn't support the option, does >>>>> that mean the option will never be passed and users will never know >>>>> that there are gaping holes in the pointer bounds checking? >>>>> >>>>> My suggestion would be to pass the option unconditionally and make >>>>> the documentation say something like >>>> >>>> >>>> This option was rejected. >>> >>> Right. There really isn't a good option here because we don't have >>> the infrastructure to query the linker's capabilities at link time. >>> >>> Though I do wonder if we could issue a warning in the case where the >>> configure test indicated -z bndplt was not supported. >>> >>> It'd obviously mean a link warning every time an end user tried to >>> use that toolchain to create a DSO or executable with MPX >>> protection. But that may be better than silently leaving some code >>> unprotected. >>> >>> >>> Jeff >>> >> >> Hi, >> >> Here is a patch to add a note in case we build dynamic MPX codes and don't >> pass '-z bndplt'. Does it look OK? >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-05-26 Ilya Enkovich <enkovich.gnu@gmail.com> >> >> * config/i386/linux-common.h (MPX_SPEC): Add link >> warning. >> >> libmpx/ >> >> 2015-05-26 Ilya Enkovich <enkovich.gnu@gmail.com> >> >> * configure.ac: Add link_mpx_warning. >> * libmpx.spec.in: Likewise. >> * configure: Regenerate. > > Is there a way to do this outside of the specs mechanism? If done in the > specs, are these warnings translated for locales? Specs seem to be the least intrusive way to emit some target specific message in the driver. I didn't want to add some new features into the driver just for this single warning. Spec files are not scanned by translator. I tried to split this spec into two parts to move message into a header file but with no success. Any ideas how it can be done? Ilya > > Jeff >
On Wed, 3 Jun 2015, Ilya Enkovich wrote: > Spec files are not scanned by translator. I tried to split this spec > into two parts to move message into a header file but with no success. > Any ideas how it can be done? If a spec in a .c or .h file contains %e or %n immediately followed by the message text (the message text being in the same string as the %e / %n - not split up with macros, etc.), then exgettext should extract the message for translation.
2015-06-03 18:25 GMT+03:00 Joseph Myers <joseph@codesourcery.com>: > On Wed, 3 Jun 2015, Ilya Enkovich wrote: > >> Spec files are not scanned by translator. I tried to split this spec >> into two parts to move message into a header file but with no success. >> Any ideas how it can be done? > > If a spec in a .c or .h file contains %e or %n immediately followed by the > message text (the message text being in the same string as the %e / %n - > not split up with macros, etc.), then exgettext should extract the message > for translation. Right. But I need to enable/disable this message during configuration. To do it I have a spec file with either note or an empty string. I also tried to do smth like: header: #define MSG "%nsome msg" #define NOTE_SPEC "%(config_spec)" MSG "}" spec file: *config_spec = %{<some_opt>: But that didn't work. Thanks, Ilya > > -- > Joseph S. Myers > joseph@codesourcery.com
On Wed, 3 Jun 2015, Ilya Enkovich wrote: > 2015-06-03 18:25 GMT+03:00 Joseph Myers <joseph@codesourcery.com>: > > On Wed, 3 Jun 2015, Ilya Enkovich wrote: > > > >> Spec files are not scanned by translator. I tried to split this spec > >> into two parts to move message into a header file but with no success. > >> Any ideas how it can be done? > > > > If a spec in a .c or .h file contains %e or %n immediately followed by the > > message text (the message text being in the same string as the %e / %n - > > not split up with macros, etc.), then exgettext should extract the message > > for translation. > > Right. But I need to enable/disable this message during configuration. You could, for example, have #if SOMETHING #define MSG "%nsome msg" #else #define MSG "" #endif and have another spec using MSG - that should work.
2015-06-03 18:59 GMT+03:00 Joseph Myers <joseph@codesourcery.com>: > You could, for example, have > > #if SOMETHING > #define MSG "%nsome msg" > #else > #define MSG "" > #endif > > and have another spec using MSG - that should work. In this case I should define SOMETHING in configure of gcc, not in configure of libmpx, right? But it would mean I check host linker, not target. Ilya > > -- > Joseph S. Myers > joseph@codesourcery.com
On Thu, 4 Jun 2015, Ilya Enkovich wrote: > 2015-06-03 18:59 GMT+03:00 Joseph Myers <joseph@codesourcery.com>: > > You could, for example, have > > > > #if SOMETHING > > #define MSG "%nsome msg" > > #else > > #define MSG "" > > #endif > > > > and have another spec using MSG - that should work. > > In this case I should define SOMETHING in configure of gcc, not in > configure of libmpx, right? But it would mean I check host linker, not > target. gcc/ configure tests on the linker generally test the build-x-target linker, which is required to have the same version and be configured the same as the host-x-target linker. (The tests mustn't actually try to link anything, but they can e.g. see if a particular option is mentioned in --help output. In general they also have version number checks for the case of an in-tree linker build.)
diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h index dd79ec6..fcaab81 100644 --- a/gcc/config/i386/linux-common.h +++ b/gcc/config/i386/linux-common.h @@ -61,7 +61,8 @@ along with GCC; see the file COPYING3. If not see #ifndef MPX_SPEC #define MPX_SPEC "\ - %{mmpx:%{fcheck-pointer-bounds:%{!static:%:include(libmpx.spec)%(link_mpx)}}}" + %{mmpx:%{fcheck-pointer-bounds:%{!static:%:include(libmpx.spec)%(link_mpx) \ + %(link_mpx_warning)}}}" #endif #ifndef LIBMPX_SPEC diff --git a/libmpx/configure.ac b/libmpx/configure.ac index 463e855..7e9ef86 100644 --- a/libmpx/configure.ac +++ b/libmpx/configure.ac @@ -40,17 +40,22 @@ AM_CONDITIONAL(LIBMPX_SUPPORTED, [test "x$LIBMPX_SUPPORTED" = "xyes"]) link_libmpx="-lpthread" link_mpx="" +link_mpx_warning="" AC_MSG_CHECKING([whether ld accepts -z bndplt]) echo "int main() {};" > conftest.c if AC_TRY_COMMAND([${CC} ${CFLAGS} -Wl,-z,bndplt -o conftest conftest.c 1>&AS_MESSAGE_LOG_FD]) then AC_MSG_RESULT([yes]) link_mpx="$link_mpx -z bndplt" + link_mpx_warning="%{mmpx:}" else AC_MSG_RESULT([no]) + link_mpx="%{mmpx:}" + link_mpx_warning="%nGCC was configured with a linker with no '-z bndplt' support. It significantly reduces MPX coverage for dynamic codes. It is strongly recommended to use GCC properly configured for MPX." fi AC_SUBST(link_libmpx) AC_SUBST(link_mpx) +AC_SUBST(link_mpx_warning) AM_INIT_AUTOMAKE(foreign no-dist no-dependencies) AM_ENABLE_MULTILIB(, ..) diff --git a/libmpx/libmpx.spec.in b/libmpx/libmpx.spec.in index 34d0bdf..854f13d 100644 --- a/libmpx/libmpx.spec.in +++ b/libmpx/libmpx.spec.in @@ -3,3 +3,5 @@ *link_libmpx: @link_libmpx@ *link_mpx: @link_mpx@ + +*link_mpx_warning: @link_mpx_warning@