On Thu, 13 Nov 2014, Ilya Enkovich wrote: > > You can leave it as a single library - it's just that imposes libgcc-like > > constraints on what the library does and how it does things, so as to be > > usable for arbitrary programs built with MPX (e.g. using > > reserved-namespace names such as __write when available - direct syscalls > > may also be a possibility in some cases). > > I really don't want to make it libgcc-like and complicate its further > development. What is the reason for that? Is it because library is > linked by -mmpx? Can it be avoided if library is linked only at > '-fcheck-pointer-bounds -mmpx' combination? If single -mmpx is used
What's -fcheck-pointer-bounds? I don't see any documentation of it in invoke.texi. Any options intended for users to use need documenting there - did a documentation patch get missed out from the series of patches posted / committed? Documentation might help understand the intent of the feature. I think there are two natural possibilities: * Use as a lightweight hardening feature enabled by default across a whole distribution (or for a subset of the distribution considered security-critical), by people who don't know the detailed requirements of individual programs built with the option. In that case there are libgcc-like requirements (as another issue there, it might be problematic to cause arbitrary previously unthreaded programs to link with libpthread; at least, performance issues seem possible). Outputting reports to files determined by environment variables is probably not a sensible approach in this case. You might want reports to syslog, or might want MPX-detected issues to be intercepted by crash reporters such as apport so they can collect relevant information and offer to report it to the distributor. * Use as a debugging tool, by people who understand the requirements of their application / library and can tell whether the things the MPX library is documented as doing might be a problem in their case. For this, libgcc-like requirements don't apply and output to files seems more sensible. If it's intended only as the latter - and this is documented - then you don't have the libgcc-like requirements, and there's no point in having multiple libraries. If it's intended for both, that points the way to separate libraries (where the debugging-tool library would be used in that use case, but the crash-reporter-interception case would expect programs to have been linked with only the minimal library). -- Joseph S. Myers jos...@codesourcery.com
