[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