On 20 September 2017 at 23:13, John Reiser wrote:
> Now that I know the nature of the conflict, then I will spend a
> handful of instructions to avoid [0xf700, +), and also the
> stack if it gets placed immediately below that.
Cool. I figured out why -R 0x
I don't really know why we use 0xf700 as our
reserved_va value here, though. Alex, you added that
years ago, can you remember why you used that value?
IIRC I wanted to map the full 32 bits of address space possibly in use by a
32bit application, but leave some room for something, but I
On 20.09.17 20:04, Peter Maydell wrote:
On 20 September 2017 at 18:05, John Reiser wrote:
Yes, the SEGV occurs on the store, "long" before the re-written
instruction ever is executed
OK, I've identified the immediate cause for this SEGV.
(1) when the guest initially
On 20 September 2017 at 18:05, John Reiser wrote:
> Yes, the SEGV occurs on the store, "long" before the re-written
> instruction ever is executed
OK, I've identified the immediate cause for this SEGV.
(1) when the guest initially mmap()s at 0xf700 and
above we pass
Thanks for your reply, Peter. [I fixed my typo in the Subject: field of the
header.]
[Moving here from https://bugzilla.redhat.com/show_bug.cgi?id=1493304 ]
qemu-arm from qemu-user-2.10.0-1.fc27.x86_64 (thus emulating 32-bit ARM on
x86_64)
generates SIGSEGV when code modifies a