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

[Jeff Law <law at redhat dot com>]

On 03/31/2015 03:47 AM, Ilya Enkovich wrote:
> On 23 Mar 13:19, Ilya Enkovich wrote:
> > Hi,
> >
> > May this patch go into trunk at this point?  It is very important for
> > dynamic MPX codes.
> >
> > Thanks,
> > Ilya
>
> I additionally documented changes in invoke.texi.  OK for trunk?
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2015-03-31  Ilya Enkovich  <ilya.enkovich@intel.com>
>
> 	PR driver/65444
> 	* config/i386/linux-common.h (MPX_SPEC): New.
> 	(CHKP_SPEC): Add MPX_SPEC.
> 	* doc/invoke.texi (-fcheck-pointer-boudns): Document
> 	possible issues with '-z bndplt' support in linker.
>
> libmpx/
>
> 2015-03-31  Ilya Enkovich  <ilya.enkovich@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.
Just to make sure I understand.  With this patch we conditionally pass 
-z bndplt based on whether or not it's supported by the linker we find 
when we configure GCC.

Failure to pass -z bndplt won't cause the program to misbehave, but will 
limit the effectiveness of MPX.

Gold doesn't support -z bndplt, just newer versions of the BFD linker.

Gold issues an error for -z bndplt, old BFD linkers will issue a warning.

There are, at least in theory, use cases where we might not have a PLT 
and thus -z bndplt wouldn't make sense anyway.

I guess the one thing I don't like here is that whether or not to pass 
-z bndplt is made at the time we configure GCC.  Yet, it's trivial for 
someone to change the system linker later, either to gold or from an old 
BFD linker that doesn't support -z bndplt to one that does support -z 
bndplt.

[ Note we have the same issue with certain assembler feature tests. ]

I'm not aware of any real infrastructure in GCC to query the behavior of 
the linker at link time and then customize the options passed.  So if 
it's going to be configurable, then that's the only time to do the test.

I strongly disagree with HJ's assertion that we should always pass the 
flag, regardless of the underlying linker.

So, in an ideal world, we'd query the linker at link time and pass the 
flag anytime we have a linker that supports the capability and perhaps 
warn if the linker doesn't support that capability.

Given we're not in that ideal world, I think Ilya's patch is reasonable 
and should be installed.

jeff