On 10 October 2017 at 11:54, Alex Bennée <alex.ben...@linaro.org> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > >> On 10 October 2017 at 10:53, Alex Bennée <alex.ben...@linaro.org> wrote: >>> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> Running the test program >>>> http://people.linaro.org/~peter.maydell/thumb-over-page >>>> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c) >>>> in the usermode emulator: >>>> ./build/x86/arm-linux-user/qemu-arm >>>> ~/linaro/qemu-misc-tests/thumb-over-page >>> >>> Does this fail when run via system mode as well? >> >> Nope, only usermode. (Makes sense, since the handle_cpu_signal() >> codepath is only used in usermode emulation.) > > But surely system emulation has to deal with the same rolling over a > page issue. How is it's resolution different?
In system emulation, the attempted load of code is via cpu_lduw_code(), which in turn calls cpu_lduw_code_ra() passing it a retaddr parameter of 0. This is then propagated through the softmmu functions until it eventually reaches tlb_fill(), which then passes it to cpu_restore_state() as the retaddr. In usermode, we don't have the softmmu at all, so cpu_lduw_code() turns into a straightforward host memory access, which is then caught by the signal handler. The signal handler can't tell whether it was invoked as a result of translated code or not, so it just passes the PC of the host memory access to cpu_restore_state(). cpu_restore_state() ought to check whether the PC it is passed is within the TCG codegen buffer. Incidentally cpu_restore_state currently says: /* A retaddr of zero is invalid so we really shouldn't have ended * up here. but this isn't true -- it's an expected result for the case where a zero retaddr was used, and we should deal with that in cpu_restore_state() rather than making every caller do that test. thanks -- PMM
