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.