On 09.10.2015 17:04, Peter Maydell wrote: > On 9 October 2015 at 14:59, Sergey Fedorov <serge.f...@gmail.com> wrote: >> On 08.10.2015 21:40, Peter Maydell wrote: >>> Annoying corner case which I don't think we need to handle necessarily: >>> if you set a breakpoint on a 32-bit Thumb instruction which spans a page >>> boundary, and the second page is not present, we will end up taking the >>> page fault when I think we should take the breakpoint. I can't think >>> of a way to get that right, so just commenting that it isn't handled >>> right would do. >> Could you please point out the piece of code which will generate the >> page fault? Maybe I will give it a thought :) > When you call arm_ldl_code() and friends, they will end up longjmp()ing > out of the codegen phase if the load faults. This then turns into a > guest-visible fault in the usual way. > > To avoid this you'd need to instead call functions which return > a transaction status, but then: > (a) you need to restructure the translate.c code so it can > deal with the idea of backing out if the instruction isn't > actually present > (b) this still wouldn't work for linux-user mode, where we > don't have any way to say "do a memory access, but let me know > if it would fail rather than longjmping"
Hm... Seems we will get the page fault instead of the CPU breakpoint not only on a 32-bit Thumb instruction which spans a page boundary but on every instruction translation fetch when the page is not present. Do I understand it correctly? Best regards, Sergey
