This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 01/10] Initial import of asan from the Google branch into trunk
Jakub Jelinek wrote:
On Fri, Nov 09, 2012 at 02:14:04PM +0100, Tobias Burnus wrote:
I tried the 01/10 to 10/10 patch series but it doesn't trigger for
the following test case:
[...]
Can't reproduce that (admittedly with asan SVN branch rather than the patchset):
I can reproduce both; comparing the asan0 dumps and the two asan.c
files, I came up with the following patch. If I apply it on top of
Dodji's branch, it now also aborts.
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1536,10 +1536,10 @@ static void
asan_init_shadow_ptr_types (void)
{
asan_shadow_set = new_alias_set ();
- shadow_ptr_types[0] = build_distinct_type_copy (unsigned_char_type_node);
+ shadow_ptr_types[0] = build_distinct_type_copy (signed_char_type_node);
TYPE_ALIAS_SET (shadow_ptr_types[0]) = asan_shadow_set;
shadow_ptr_types[0] = build_pointer_type (shadow_ptr_types[0]);
- shadow_ptr_types[1] = build_distinct_type_copy (short_unsigned_type_node);
+ shadow_ptr_types[1] = build_distinct_type_copy (short_integer_type_node);
TYPE_ALIAS_SET (shadow_ptr_types[1]) = asan_shadow_set;
shadow_ptr_types[1] = build_pointer_type (shadow_ptr_types[1]);
}
Other remarks:
* libsanitizer: It currently installs under "lib" even under a
x86-64-gnu-linux system where it should be "lib64"; that's probably
automatically fix by enabling the multilib support. Maybe, removing the
"#" before "#AM_ENABLE_MULTILIB" in libsanitizer/configure.ac is sufficient
* invoke.texi: The fbranch-target-load-optimize2 and fauto-inc-dec lost
the "-", additionally, there are several "--f…" items.
Tobias
PS: Has someone an idea why I cannot run the -faddress-sanitizer
executable on gcc20 of the GCC compile farm? Fails with the following
message, but "ulimit -v" is set to "unlimited".
==4784== ReserveShadowMemoryRange failed while trying to map
0x20000001000 bytes. Perhaps you're using ulimit -v