[PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX

Ilya Enkovich enkovich.gnu@gmail.com
Wed Jun 3 09:04:00 GMT 2015


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
>



More information about the Gcc-patches mailing list