Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

qemu-arm / libsanitizer compatibility? #160

Closed
ramosian-glider opened this issue Aug 31, 2015 · 13 comments
Closed

qemu-arm / libsanitizer compatibility? #160

ramosian-glider opened this issue Aug 31, 2015 · 13 comments
Labels
Priority-Medium ProjectAddressSanitizer Status-WontFix Type-Defect

Comments

@ramosian-glider
Copy link
Member

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
Copy link
Member Author 

>> 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
Copy link
Member Author 

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
Copy link
Member Author 

>> 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
Copy link
Member Author 

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
Copy link
Member Author 

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
Copy link
Member Author 

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
Copy link
Member Author 

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
Copy link
Member Author 

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

@ramosian-glider
Copy link
Member Author 

>> README.gcc file says to run merge.sh
Correct. But I am ok with this particular patch to go separately.
Next time I do the merge, there will be no merge conflict, because the patch is already
in LLVM trunk. 

I don't have plans to do a merge to GCC,
probably until LeakSanitizer is fully functional (a couple of months from now).

Reported by konstantin.s.serebryany on 2013-05-31 10:25:17

@ramosian-glider
Copy link
Member Author 

In GCC trunk: http://gcc.gnu.org/viewcvs?rev=199606&root=gcc&view=rev

Reported by konstantin.s.serebryany on 2013-06-03 13:40:16

@ramosian-glider
Copy link
Member Author 

christophe.lyon@gmail.com: you got it working on Qemu ?

Reported by kumarsukhani on 2014-04-23 11:17:05

@ramosian-glider
Copy link
Member Author 

Yes, I regularly use qemu. Be sure to use -R 0 as said in comment #5.

Maybe you also need to disable ASLR (address randomization), you can do that with
setarch x86_64 -R

Reported by christophe.lyon on 2014-04-23 12:42:35

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:13:40

  • Labels added: ProjectAddressSanitizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority-Medium ProjectAddressSanitizer Status-WontFix Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider