From: Stafford Horne <shorne@gmail.com> To: Richard Henderson <rth@twiddle.net> Cc: Jia Liu <proljc@gmail.com>, qemu-devel@nongnu.org, openrisc@lists.librecores.org Subject: Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers Date: Wed, 8 Feb 2017 23:01:20 +0900 [thread overview] Message-ID: <20170208140120.GI32144@lianli.shorne-pla.net> (raw) In-Reply-To: <d3dac109-ad39-8bb9-2012-f7a6824139eb@twiddle.net> On Mon, Feb 06, 2017 at 09:53:26PM -0800, Richard Henderson wrote: > On 02/01/2017 02:04 AM, Stafford Horne wrote: > > For kernel builds I have created toolchain binaries here: > > > > http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/ > > > > These should work. > > This gdb crashes on the first "stepi" that I issue. To reproduce, > > $ cat z.c > int main() { return 0; } > $ or1k-musl-linux-gcc -g z.c > $ qemu-or32 -g 10001 ./a.out > > // another window > > $ or1k-musl-linux-gdb ./a.out > (gdb) target remote localhost:10001 > // should see that the pc is at _start > (gdb) stepi > // crash > > I won't be able to debug this myself until I can build my own gdb. Hello, The gdb branch I use is the following, it is tracking very close to upsstream: git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream I have sent this for review to the gdb list and currently waiting on comments for version 4. Most of the code is the same as in openrisc github. However, I have just rebased and cleaned up for upstreaming. Note, I can get basic programs running fine on your qemu branch using linux-user i.e. $ cat main.c #include <stdio.h> int main() { printf("hello"); return 0; } $ or1k-linux-musl-gcc -g -static main.c $ ./qemu/build/or32-linux-user/qemu-or32 ./a.out hello However, when debugging I ran into a few errors. 1. qemu aborts the program and sends SIGILL to gdb, this is caused by the openrisc loop in linux-user missing handlers for EXCP_INTERRUPT and EXCP_DEBUG, I patched that see below: 2. After patching I got 1 step to work then gdb crashes with SIGSEGV Currently looking at it, Interestingly the code that is failing is in gdb/or1k-tdep.c: or1k_single_step_through_delay() cgen_lookup_insn() - returns NULL (shouldnt happen though) then NULL is dereferenced Interesting because it seems you wrote cgen_lookup_insn :) I am investigating more, but it seems like gdb issue. Notes on the debugger: - The support for linux user processes is not implemented. Eventually I think it will crash somewhere. But it shouldnt crash where it is. - I tested the same program with the baremetal (newlib) toolchain * gdb native sim - OK can debug * or1ksim (via target remote) - Crashes same as QEMU -Stafford Patch for qemu issue mentioned in (1) above. >From 777bd1c6641ea919799579dfbc99db4338db11bf Mon Sep 17 00:00:00 2001 From: Stafford Horne <shorne@gmail.com> Date: Wed, 8 Feb 2017 22:20:01 +0900 Subject: [PATCH] linux-user: openrisc: Implement EXCP_INTERRUPT and EXCP_DEBUG These were not implemented. They are required escpecially if we want to debug user processes in openrisc. Signed-off-by: Stafford Horne <shorne@gmail.com> --- linux-user/main.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/linux-user/main.c b/linux-user/main.c index 94a636f..1c33378 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -2468,6 +2468,7 @@ void cpu_loop(CPUOpenRISCState *env) { CPUState *cs = CPU(openrisc_env_get_cpu(env)); int trapnr, gdbsig; + target_siginfo_t info; abi_long ret; for (;;) { @@ -2542,6 +2543,23 @@ void cpu_loop(CPUOpenRISCState *env) case EXCP_ATOMIC: cpu_exec_step_atomic(cs); break; + case EXCP_INTERRUPT: + /* just indicate that signals should be handled asap */ + break; + case EXCP_DEBUG: + { + int sig; + + sig = gdb_handlesig(cs, TARGET_SIGTRAP); + if (sig) + { + info.si_signo = sig; + info.si_errno = 0; + info.si_code = TARGET_TRAP_BRKPT; + queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info); + } + } + break; default: EXCP_DUMP(env, "\nqemu: unhandled CPU exception %#x - aborting\n", trapnr); -- 2.9.3
WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com> To: openrisc@lists.librecores.org Subject: [OpenRISC] [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers Date: Wed, 8 Feb 2017 23:01:20 +0900 [thread overview] Message-ID: <20170208140120.GI32144@lianli.shorne-pla.net> (raw) In-Reply-To: <d3dac109-ad39-8bb9-2012-f7a6824139eb@twiddle.net> On Mon, Feb 06, 2017 at 09:53:26PM -0800, Richard Henderson wrote: > On 02/01/2017 02:04 AM, Stafford Horne wrote: > > For kernel builds I have created toolchain binaries here: > > > > http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/ > > > > These should work. > > This gdb crashes on the first "stepi" that I issue. To reproduce, > > $ cat z.c > int main() { return 0; } > $ or1k-musl-linux-gcc -g z.c > $ qemu-or32 -g 10001 ./a.out > > // another window > > $ or1k-musl-linux-gdb ./a.out > (gdb) target remote localhost:10001 > // should see that the pc is at _start > (gdb) stepi > // crash > > I won't be able to debug this myself until I can build my own gdb. Hello, The gdb branch I use is the following, it is tracking very close to upsstream: git at github.com:stffrdhrn/binutils-gdb.git or1k-upstream I have sent this for review to the gdb list and currently waiting on comments for version 4. Most of the code is the same as in openrisc github. However, I have just rebased and cleaned up for upstreaming. Note, I can get basic programs running fine on your qemu branch using linux-user i.e. $ cat main.c #include <stdio.h> int main() { printf("hello"); return 0; } $ or1k-linux-musl-gcc -g -static main.c $ ./qemu/build/or32-linux-user/qemu-or32 ./a.out hello However, when debugging I ran into a few errors. 1. qemu aborts the program and sends SIGILL to gdb, this is caused by the openrisc loop in linux-user missing handlers for EXCP_INTERRUPT and EXCP_DEBUG, I patched that see below: 2. After patching I got 1 step to work then gdb crashes with SIGSEGV Currently looking at it, Interestingly the code that is failing is in gdb/or1k-tdep.c: or1k_single_step_through_delay() cgen_lookup_insn() - returns NULL (shouldnt happen though) then NULL is dereferenced Interesting because it seems you wrote cgen_lookup_insn :) I am investigating more, but it seems like gdb issue. Notes on the debugger: - The support for linux user processes is not implemented. Eventually I think it will crash somewhere. But it shouldnt crash where it is. - I tested the same program with the baremetal (newlib) toolchain * gdb native sim - OK can debug * or1ksim (via target remote) - Crashes same as QEMU -Stafford Patch for qemu issue mentioned in (1) above. From 777bd1c6641ea919799579dfbc99db4338db11bf Mon Sep 17 00:00:00 2001 From: Stafford Horne <shorne@gmail.com> Date: Wed, 8 Feb 2017 22:20:01 +0900 Subject: [PATCH] linux-user: openrisc: Implement EXCP_INTERRUPT and EXCP_DEBUG These were not implemented. They are required escpecially if we want to debug user processes in openrisc. Signed-off-by: Stafford Horne <shorne@gmail.com> --- linux-user/main.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/linux-user/main.c b/linux-user/main.c index 94a636f..1c33378 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -2468,6 +2468,7 @@ void cpu_loop(CPUOpenRISCState *env) { CPUState *cs = CPU(openrisc_env_get_cpu(env)); int trapnr, gdbsig; + target_siginfo_t info; abi_long ret; for (;;) { @@ -2542,6 +2543,23 @@ void cpu_loop(CPUOpenRISCState *env) case EXCP_ATOMIC: cpu_exec_step_atomic(cs); break; + case EXCP_INTERRUPT: + /* just indicate that signals should be handled asap */ + break; + case EXCP_DEBUG: + { + int sig; + + sig = gdb_handlesig(cs, TARGET_SIGTRAP); + if (sig) + { + info.si_signo = sig; + info.si_errno = 0; + info.si_code = TARGET_TRAP_BRKPT; + queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info); + } + } + break; default: EXCP_DUMP(env, "\nqemu: unhandled CPU exception %#x - aborting\n", trapnr); -- 2.9.3
next prev parent reply other threads:[~2017-02-08 14:01 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-13 21:57 [OpenRISC] [PATCH] target-openrisc: Fix exception handling status registers Stafford Horne 2017-01-13 22:02 ` Stafford Horne 2017-01-14 4:29 ` Jia Liu 2017-01-14 8:04 ` [Qemu-devel] " Stafford Horne 2017-01-14 8:04 ` [OpenRISC] " Stafford Horne 2017-01-20 16:39 ` [Qemu-devel] " Stafford Horne 2017-01-20 16:39 ` [OpenRISC] " Stafford Horne 2017-01-23 18:08 ` [Qemu-devel] " Richard Henderson 2017-01-23 18:08 ` [OpenRISC] " Richard Henderson 2017-01-24 10:26 ` Stafford Horne 2017-01-24 10:26 ` [OpenRISC] " Stafford Horne 2017-01-24 18:32 ` Richard Henderson 2017-01-24 18:32 ` [OpenRISC] " Richard Henderson 2017-01-25 12:34 ` Stafford Horne 2017-01-25 12:34 ` [OpenRISC] " Stafford Horne 2017-01-25 17:27 ` Richard Henderson 2017-01-25 17:27 ` [OpenRISC] " Richard Henderson 2017-01-26 13:12 ` Stafford Horne 2017-01-26 13:12 ` [OpenRISC] " Stafford Horne 2017-01-26 17:26 ` Richard Henderson 2017-01-26 17:26 ` [OpenRISC] " Richard Henderson 2017-01-26 22:01 ` Stafford Horne 2017-01-26 22:01 ` [OpenRISC] " Stafford Horne 2017-02-01 10:04 ` Stafford Horne 2017-02-01 10:04 ` [OpenRISC] " Stafford Horne 2017-02-01 18:15 ` Richard Henderson 2017-02-01 18:15 ` [OpenRISC] " Richard Henderson 2017-02-02 14:34 ` Stafford Horne 2017-02-02 14:34 ` [OpenRISC] " Stafford Horne 2017-02-03 15:14 ` Stafford Horne 2017-02-03 15:14 ` [OpenRISC] " Stafford Horne 2017-02-07 2:36 ` Richard Henderson 2017-02-07 2:36 ` [OpenRISC] " Richard Henderson 2017-02-06 20:44 ` Richard Henderson 2017-02-07 0:31 ` Stafford Horne 2017-02-07 5:48 ` Richard Henderson 2017-02-07 5:53 ` Richard Henderson 2017-02-07 5:53 ` [OpenRISC] " Richard Henderson 2017-02-08 14:01 ` Stafford Horne [this message] 2017-02-08 14:01 ` Stafford Horne 2017-02-08 16:38 ` Stafford Horne 2017-02-08 16:38 ` [OpenRISC] " Stafford Horne 2017-02-08 20:38 ` Richard Henderson 2017-02-08 20:38 ` [OpenRISC] " Richard Henderson 2017-01-13 22:00 Stafford Horne
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170208140120.GI32144@lianli.shorne-pla.net \ --to=shorne@gmail.com \ --cc=openrisc@lists.librecores.org \ --cc=proljc@gmail.com \ --cc=qemu-devel@nongnu.org \ --cc=rth@twiddle.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.