On 16.03.2015 15:05, Peter Maydell wrote:
I took the liberty of rewriting the commit message a bit to better
fit in with QEMU's usual style; hope that's OK:
Sure, it is fine :)
-- Mikhail
Here is a sample to prove the issue
$ echo "int main() { return 0; }" > /tmp/prog.c
$ arm-linux-gnueabi-gcc -g -o /tmp/prog /tmp/prog.c
$ qemu-arm -cpu cortex-a15 -L
/home/michail/arm/arm-linux-gnueabi/sys-root /tmp/prog
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmen
ping
http://patchwork.ozlabs.org/patch/386918/
On 22.09.2014 13:04, Mikhail Ilin wrote:
ping
http://patchwork.ozlabs.org/patch/386918/
On 08.09.2014 17:28, m.i...@samsung.com wrote:
From: Mikhail Ilyin
The initial base address is miscalculated in walk_memory_regions().
It has to be
ping
http://patchwork.ozlabs.org/patch/386918/
On 08.09.2014 17:28, m.i...@samsung.com wrote:
From: Mikhail Ilyin
The initial base address is miscalculated in walk_memory_regions().
It has to be shifted TARGET_PAGE_BITS more. Holder variables are
extended to target_ulong size otherwise they d
I've also found that this issue in walker API leads to creating
a misformed core file. elf_core_dump() uses walk_memory_regions()
to build memory mapping for a core file.
As a result the core file has a very small size and doesn't contain
page snapshots of mapped libraries.
I've compiled a simp
Thanks,
I've tested the sample for Aarch64 myself and found that the
approach should also work fine.
Translation layout:
$ qemu-aarch64 -strace /tmp/busybox-static cat /proc/self/maps
startend size prot
0040-005ba000 001ba000 r-x
ping
http://patchwork.ozlabs.org/patch/372865/
On 23.07.2014 14:44, Mikhail Ilin wrote:
> Hi,
>
> I've enabled DEBUG_MMAP in linux-user/mmap.c and got debug info of memory
> layout.
>
> This is the debug output of guest memory layout from qemu (including
> the
ping
http://patchwork.ozlabs.org/patch/374162/
On 28.07.2014 16:02, Mikhail Ilin wrote:
Hi,
As it was posted earlier the output of reading /proc/self/maps is not
correct for a guest. There are some issues:
https://bugs.launchpad.net/qemu/+bug/1346784
http://lists.nongnu.org/archive/html/qemu
Hi,
As it was posted earlier the output of reading /proc/self/maps is not
correct for a guest. There are some issues:
https://bugs.launchpad.net/qemu/+bug/1346784
http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html
http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg0279
Hi,
I've enabled DEBUG_MMAP in linux-user/mmap.c and got debug info of memory
layout.
This is the debug output of guest memory layout from qemu (including
the last mmap call marked with *).
mmap: start=0x0804a000 len=0x00021000 prot=rw- flags=MAP_ANON
MAP_PRIVATE fd=0 offset=
ret=0x08
Adding Riku Voipio
On 18.07.2014 11:42, Mikhail Ilin wrote:
Hi,
Running 32-bits binaries with address sanitizer (ASAN) instrumentations
fails under 64-bits qemu. During initialization ASAN relies on the output
from /proc/self/mmap then tries to find a big chunk for shadow memory but
it is not
Adding Riku Voipio
On 23.07.2014 09:04, Mikhail Ilin wrote:
On 22.07.2014 12:51, Peter Maydell wrote:
> I think the ifdefs are just accident of history and we can safely remove
> them.
>
Good, let make a fix.
From 719f4e66b134a043dabdf5f6cb6d40445a53e071 Mon Sep 17 00:00:00
On 22.07.2014 12:51, Peter Maydell wrote:
> I think the ifdefs are just accident of history and we can safely remove
> them.
>
Good, let make a fix.
From 719f4e66b134a043dabdf5f6cb6d40445a53e071 Mon Sep 17 00:00:00 2001
From: Mikhail Ilyin
Date: Wed, 23 Jul 2014 08:49:09 +0400
Subject: [PATCH]
Hi,
Running 32-bits binaries with address sanitizer (ASAN) instrumentations
fails under 64-bits qemu. During initialization ASAN relies on the output
from /proc/self/mmap then tries to find a big chunk for shadow memory but
it is not happened.
Reserved memory for guest address space is used priv
14 matches
Mail list logo
