On 04/06/2015 11:14 AM, Sandra Loosemore wrote:
On 04/06/2015 09:17 AM, Ilya Enkovich wrote:
On 05 Apr 19:44, Sandra Loosemore wrote:
On 04/03/2015 01:34 PM, Joseph Myers wrote:
On Tue, 31 Mar 2015, Ilya Enkovich wrote:
+library. It also passes '-z bndplt' to a linker in case it
supports this
+option (which is checked on libmpx configuration). Note that old
versions
+of linker may ignore option. Gold linker doesn't support '-z bndplt'
+option. With no '-z bndplt' support in linker all calls to
dynamic libraries
+lose passed bounds reducing overall protection level. It's highly
+recommended to use linker with '-z bndplt' support. In case such
linker
+is not available it is adviced to always use
@option{-static-libmpxwrappers}
+for better protection level or use @option{-static} to completely
avoid
+external calls to dynamic libraries. MPX-based instrumentation
Use @samp{-z bndplt} rather than '' quoting (but Sandra may have
further
advice on the substance of this documentation).
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.
Hrmmmm, how about then just *never* passing the magic option to the
linker, and telling users they either have to pass it manually (and use
a linker that supports it), use static linking, or do without bounds
checking on dynamic libraries?
Remember that most GCC users do not configure GCC themselves... they
use whatever came with their distro or from their toolchain vendor, or
was installed by their sysadmin. So most GCC users have no way to know
what linker their GCC binary was configured with and it's just confusing
that this important linker option might or might not be included based
on factors they don't know about or can't control.
But the same arguments apply to forcing the user to manually pass the
argument, select static linking, etc.
If I think about the most common case usage, it's going to be a
compiler/binutils pair built by a distribution such as Fedora, Ubuntu,
etc and the configure time test will do the right thing. It's only
cases where folks are updating components separately, or building
themselves that the configure time test falls down.
Jeff
