Re: [Qemu-devel] qemu-arm SIGSEGV for self-modifying code

2017-10-03 Thread Peter Maydell
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

Re: [Qemu-devel] qemu-arm SIGSEGV for self-modifying code

2017-09-20 Thread John Reiser
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

Re: [Qemu-devel] qemu-arm SIGSEGV for self-modifying code

2017-09-20 Thread Alexander Graf
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

Re: [Qemu-devel] qemu-arm SIGSEGV for self-modifying code

2017-09-20 Thread Peter Maydell
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

Re: [Qemu-devel] qemu-arm SIGSEGV for self-modifying code

2017-09-20 Thread John Reiser
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