qemu-arm / libsanitizer compatibility?

[ramosian-glider]

Originally reported on Google Code with ID 160

Hi,
I have added a small patch to GCC to enable libsanitizer for arm-linux.

I have cross-compiled a sample program with -fsanitize-address
and it executes correctly on an ARM board.

Now I would like to execute it under qemu-arm, but this fails.
Note that I first had to patch qemu so that its output of /proc/self/maps is compatible
with libsanitizer, but maybe libsanitizer should be patched instead:
scall.c b/linux-user/syscall.c
index a148d9f..3b0ca86 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5016,7 +5016,7 @@ static int open_self_maps(void *cpu_env, int fd)
                     " %c%c%c%c %08" PRIx64 " %02x:%02x %d%s%s\n",
                     h2g(min), h2g(max), flag_r, flag_w,
                     flag_x, flag_p, offset, dev_maj, dev_min, inode,
-                    path[0] ? "          " : "", path);
+                    path[0] ? "          " : " ", path);
         }
     }

I suppose you can do the same thing using the LLVM compiler to produce an arm-linux
executable.

Now, here are the error messages printed by libsanitizer when executed under qemu:
qemu-arm -L /home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/sysroot
./sanitizer.armhf 
==30022== Shadow memory range interleaves with an existing memory mapping. ASan cannot
proceed correctly. ABORTING.
** shadow start 0x1ffff000 shadow_end 0x3fffffff
==30022== Process memory map follows:
    0x00000000-0x00008000   
    0x00008000-0x00009000   /home/lyon/src/tests/sanitizer.armhf
    0x00009000-0x00010000   
    0x00010000-0x00011000   /home/lyon/src/tests/sanitizer.armhf
    0x00011000-0xf4f50000   
    0xf4f50000-0xf4f52000   
    0xf4f52000-0xf4f54000   
    0xf4f54000-0xf4f58000   
    0xf4f58000-0xf4f5c000   
    0xf4f5c000-0xf4f60000   
    0xf4f60000-0xf4fa3000   /home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/tools/arm-none-linux-gnueabi/lib/libgcc_s.so.1
    0xf4fa3000-0xf4faa000   /home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/tools/arm-none-linux-gnueabi/lib/libgcc_s.so.1

[.....] quite a few other regions follow.

As I am not familiar yet with libsanitizer, and probably not enough with qemu either,
I wonder whether I can expect this combination to work or not by design.

Thanks.

Reported by christophe.lyon on 2013-02-15 14:32:39

[ramosian-glider]

>> but maybe libsanitizer should be patched instead
patches are welcome. It's hard for us to come with a patch since we can't test it.

>>  0x00011000-0xf4f50000   
This is the culprit. 
quemu for some reason maps almost all of the address space leaving no space for asan.

Reported by konstantin.s.serebryany on 2013-02-15 14:40:57

[ramosian-glider]

The patch I talked about is about parsing the output of /proc/self/maps: the linux kernel
seems to add a ' ' after the last number if there is no filename, which sanitizer_linux.cc:MemoryMappingLayout::Next()
depends on. Maybe the
  CHECK_EQ(*current_++, ' ');
just before the // Skip spaces should be optional since qemu does not add this ' '
(which is what my qemu patch above does.... not sure if qemu guys would accept it)

regarding the strange mapping, I understand you suggest I should ask on qemu list,
right?

Reported by christophe.lyon on 2013-02-15 14:48:14

[ramosian-glider]

>> CHECK_EQ(*current_++, ' ');
Does removing the check helps you? 
I'd still ask quemu why do they have different spacing than the real linux. 

>> regarding the strange mapping, I understand you suggest I should ask on qemu list,
right?

Yes

Reported by konstantin.s.serebryany on 2013-02-18 04:07:08

[ramosian-glider]

This is not actionable, please reopen if there is something we can/should do.

Reported by konstantin.s.serebryany on 2013-03-14 11:04:13

• Status changed: WontFix

[ramosian-glider]

Workaround for the address space problem: invoke qemu with -R 0

Reported by konstantin.s.serebryany on 2013-03-28 07:34:33

[ramosian-glider]

I'd like you to consider the following patch:
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc b/libsanitizer/sanitizer_common/sanitizer_lin
index 3d39ae0..7599ea9 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -440,7 +440,6 @@ bool MemoryMappingLayout::Next(uptr *start, uptr *end, uptr *offset,
   CHECK_EQ(*current_++, ' ');
   while (IsDecimal(*current_))
     current_++;
-  CHECK_EQ(*current_++, ' ');
   // Skip spaces.
   while (current_ < next_line && *current_ == ' ')
     current_++;

It would allow to work with legacy qemu, until fixed versions reach the users. (My
qemu patch has been accepted upstream, but was not integrated in the recent 1.15 release.
The above patch allows GCC developers to work with libsanitizer using existing qemu).

Reported by christophe.lyon@linaro.org on 2013-05-29 22:05:46

[ramosian-glider]

I've committed http://llvm.org/viewvc/llvm-project?rev=182922&view=rev to LLVM trunk.
It think it's fine if you commit the same patch to GCC, both 4.8 and trunk
(I was not planing any new merges to GCC in the near future)

Reported by konstantin.s.serebryany on 2013-05-30 11:05:48

[ramosian-glider]

In GCC's libsanitizer directory, the README.gcc file says to run merge.sh, but the current
revision is 175733, vs 182922 for this patch. It makes a large difference.

Do I really have to run merge.sh or should I only backport these few lines? (But then,
what about next merge?)

Reported by christophe.lyon on 2013-05-30 15:37:49