On 09/12/2018 12:39 PM, Alex Bennée wrote:
Richard Henderson <richard.hender...@linaro.org> writes:
On 09/11/2018 02:29 PM, Sandra Loosemore wrote:
Without this patch, QEMU exits immediately when it execution stops at
a breakpoint, instead of reporting it to GDB.
Signed-off-by: Sandra Loosemore <san...@codesourcery.com>
---
linux-user/nios2/cpu_loop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/nios2/cpu_loop.c b/linux-user/nios2/cpu_loop.c
index dac7a06..a5ae37f 100644
--- a/linux-user/nios2/cpu_loop.c
+++ b/linux-user/nios2/cpu_loop.c
@@ -71,6 +71,9 @@ void cpu_loop(CPUNios2State *env)
gdbsig = TARGET_SIGTRAP;
break;
}
+ case EXCP_DEBUG:
+ gdbsig = TARGET_SIGTRAP;
+ break;
This really isn't complete. You set gdbsig from odd places instead of using
queue_signal; you fail to honor the return value from gdb_handlesig.
But I suppose those should be separate patches, so
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
At least the cpu_loops have been separated now.. I guess the next step
is to audit each one for common features? There do seem to be some magic
numbers in the nios loop which I find concerning.
I'm not sure where the 0xaa value came from, but it is used to indicate
syscalls through the kuser page mapped at address 0x1000 in user space.
The addresses are a fixed ABI although not terribly well-documented
AFAICT. There's code in target/nios2 that catches attempts to execute
code on that page, and in the Linux kernel the code that goes on the
kuser page is at the end of arch/nios2/kernel/entry.S. This all could
certainly be better documented in the QEMU cpu_loop code too.
-Sandra
