All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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: link
Be 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.