This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Report on the bounded pointers work
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, fweimer at redhat dot com, gcc <gcc at gcc dot gnu dot org>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>, Evgeny Gavrin <e dot gavrin at samsung dot com>
- Date: Tue, 5 Nov 2013 18:28:06 +0100
- Subject: Re: Report on the bounded pointers work
- Authentication-results: sourceware.org; auth=none
- References: <5278C46C dot 7090802 at samsung dot com> <527922C7 dot 3010600 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Nov 05, 2013 at 09:54:31AM -0700, Jeff Law wrote:
> On 11/05/13 03:11, Yury Gribov wrote:
> > > If you're referring to mudflap (Frank Eigler's work),
> > > ...
> > > It never reached a point where interoperability across objects with
> >and without mudflap instrumentation worked
> >Could you add more details? E.g. I don't see how mudflap
> >interoperability is different from AdressSanitizer which seems to be
> >state of the art.
> I haven't looked at AddressSanitizer, so I can't really comment on
> if/how it handles code interoperability.
Asan is conservative, you can mix instrumented and uninstrumented code.
There are some issues if you don't link the binary with -fsanitize=address
(both that the library may be initialized too late to work properly and that
it's entry points that are meant to override libc/libpthread/libstdc++ entry
points aren't early enough in symbol search scope), but some libraries are
instrumented, but other than that it should work fine. Also, one issue is
the large address space requirements (so you can't use too low RLIMIT_AS).
As for speed, I guess it remains to be measured which of asan vs. MPX is
faster (and, if MPX grows some variant without HW support, also how well
that one works compared to asan).
Jakub