[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

["dvyukov at google dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309

--- Comment #35 from Dmitry Vyukov <dvyukov at google dot com> 2013-02-12 08:47:21 UTC ---
On Tue, Feb 12, 2013 at 12:39 PM, jakub at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
>
> --- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-12 08:39:33 UTC ---
> (In reply to comment #32)
>> Good news, 0x7fff8000 seems great:
>> There is another suggestion (from dvyukov) to use -Wl,-Ttext-segment=0x40000000
>> together with zerobase (pie is not required) which is worth investigating.
>
> Glad to hear that.  The disadvantage of
> -Wl,-Ttext-segment=0x40000000 is that it requires special command line option
> for building the executable, i.e. you can't e.g. just build some shared library
> with -fsanitize=address and leave the main executable non-instrumented.
> Plus, I don't see how can
> -Wl,-Ttext-segment=0x40000000 be used for x86_64, where you need 16TB of shadow
> memory for >> 3 scale.  For zero shadow offset you'd need to place the
> executable above 16TB, and that implies non-small model.

It is intended for x86_64. The binary is situated at 0x40000000 and
it's shadow is at 0x10000000-0x3fffffff (MAP_32BIT can live here as
well).
Dynamic libraries and mmap live either at 0x7fxxxxxxxxxx or at
0x55xxxxxxxxxx, that is mapped way above the executable. So there are
no overlaps.





> If -Ttext-segment is meant for 32-bit programs, then it could allow zero shadow
> offset, but with the disadvantage of special building of executables, and on
> i?86 the offset already fits into the immediates, so it is basically the
> 0x7fff8000 case for x86_64 already.
>
> (In reply to comment #33)
>> > , it might be better to have the scale
>> > and offset as arguments of __asan_init?
>>
>> We did this in the very early version, but it did not work in general.
>> Consider you are linking your program with a third-party object
>> not built with asan. It may have constructor functions called before main and
>> before __asan_init, and those functions call malloc which has to
>> call __asan_init, but can not pass arguments.
>
> I see, but then you could use the global vars (perhaps weak ones in libasan
> with some default), combined together with arguments to __asan_init (or some
> alternative name of the same function for compatibility).  All that it would do
> beyond normal initialization would be complain if the requested scale/offset
> pair is different from the chosen one.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.