On Wed, Mar 18, 2015 at 1:25 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Wed, Mar 18, 2015 at 5:13 AM, Ilya Enkovich <enkovich....@gmail.com> wrote:
>> 2015-03-18 15:08 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>:
>>> On Wed, Mar 18, 2015 at 5:05 AM, Ilya Enkovich <enkovich....@gmail.com> 
>>> wrote:
>>>> 2015-03-18 15:02 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>:
>>>>> On Wed, Mar 18, 2015 at 4:56 AM, Ilya Enkovich <enkovich....@gmail.com> 
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This patch fixes PR target/65444 by passing '-z bndplt' to linker when 
>>>>>> appropriate.  Bootstrapped and tested on x86_64-unknown-linux-gnu.  Will 
>>>>>> commit it to trunk in a couple of days if no objections arise.
>>>>>>
>>>>>> Thanks,
>>>>>> Ilya
>>>>>> --
>>>>>> gcc/
>>>>>>
>>>>>> 2015-03-18  Ilya Enkovich  <ilya.enkov...@intel.com>
>>>>>>
>>>>>>         PR driver/65444
>>>>>>         * config/i386/linux-common.h (MPX_SPEC): New.
>>>>>>         (CHKP_SPEC): Add MPX_SPEC.
>>>>>>
>>>>>> libmpx/
>>>>>>
>>>>>> 2015-03-18  Ilya Enkovich  <ilya.enkov...@intel.com>
>>>>>>
>>>>>>         PR driver/65444
>>>>>>         * configure.ac: Add check for '-z bndplt' support
>>>>>>         by linker. Add link_mpx output variable.
>>>>>>         * libmpx.spec.in (link_mpx): New.
>>>>>>         * configure: Regenerate.
>>>>>>
>>>>>>
>>>>>> diff --git a/gcc/config/i386/linux-common.h 
>>>>>> b/gcc/config/i386/linux-common.h
>>>>>> index 9c6560b..dd79ec6 100644
>>>>>> --- a/gcc/config/i386/linux-common.h
>>>>>> +++ b/gcc/config/i386/linux-common.h
>>>>>> @@ -59,6 +59,11 @@ along with GCC; see the file COPYING3.  If not see
>>>>>>   %:include(libmpx.spec)%(link_libmpx)"
>>>>>>  #endif
>>>>>>
>>>>>> +#ifndef MPX_SPEC
>>>>>> +#define MPX_SPEC "\
>>>>>> + 
>>>>>> %{mmpx:%{fcheck-pointer-bounds:%{!static:%:include(libmpx.spec)%(link_mpx)}}}"
>>>>>> +#endif
>>>>>> +
>>>>>>  #ifndef LIBMPX_SPEC
>>>>>>  #if defined(HAVE_LD_STATIC_DYNAMIC)
>>>>>>  #define LIBMPX_SPEC "\
>>>>>> @@ -89,5 +94,5 @@ along with GCC; see the file COPYING3.  If not see
>>>>>>
>>>>>>  #ifndef CHKP_SPEC
>>>>>>  #define CHKP_SPEC "\
>>>>>> -%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}"
>>>>>> +%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}" 
>>>>>> MPX_SPEC
>>>>>>  #endif
>>>>>> diff --git a/libmpx/configure.ac b/libmpx/configure.ac
>>>>>> index fe0d3f2..3f8b50f 100644
>>>>>> --- a/libmpx/configure.ac
>>>>>> +++ b/libmpx/configure.ac
>>>>>> @@ -40,7 +40,18 @@ AC_MSG_RESULT($LIBMPX_SUPPORTED)
>>>>>>  AM_CONDITIONAL(LIBMPX_SUPPORTED, [test "x$LIBMPX_SUPPORTED" = "xyes"])
>>>>>>
>>>>>>  link_libmpx="-lpthread"
>>>>>> +link_mpx=""
>>>>>> +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"
>>>>>> +else
>>>>>> +    AC_MSG_RESULT([no])
>>>>>> +fi
>>>>>>  AC_SUBST(link_libmpx)
>>>>>> +AC_SUBST(link_mpx)
>>>>>>
>>>>>
>>>>> Without -z bndplt, MPX won't work correctly.  We should always pass -z 
>>>>> bndplt
>>>>> to linker.  If linker doesn't support it, ld will issue a warning, not
>>>>> error and users
>>>>> will know their linker is too old.  When they update linker, they don't 
>>>>> have to
>>>>> rebuild GCC.
>>>>
>>>> If ld issues a warning instead of an error, then configure test passes
>>>> and we pass '-z bndplt' to linker.
>>>>
>>>
>>> Can you verify it with an older linker? The unknown XXX in -z XXX is always
>>> warned and ignored in Linux linker.  If testing it on Linux always passes,
>>> it is useless.
>>
>> Old ld issues a warning:
>>
>> ld: warning: -z bndplt ignored.
>
> Does configure test pass?
>
>> But gold issues an error:
>>
>> ld.gold: bndplt: unknown -z option
>> ld.gold: use the --help option for usage information
>
> If gold is used, MPX won't work.  What should we do here?
> Should we hardcode -fuse-ld=bfd for MPX?

Is MPX disabled when the host linker is gold and gld isn't available?

Richard.

> --
> H.J.

Reply via email to