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 didn't work and have sent
a
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 don'
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 mmap()s at 0xf700 a
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 that through to the host
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 never-previou
