Hello,
On Wed, Feb 08, 2017 at 11:01:20PM +0900, Stafford Horne wrote:
> 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:
>
> g...@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.
OK, I think I fixed this cgen_lookup_insn issue.
Now I can debug qemu user:
$ ./qemu/build/or32-linux-user/qemu-or32 -g 10001 ./a.out
$ or1k-linux-musl-gdb ./a.out \
--eval-command='target remote localhost:10001'
Remote debugging using localhost:10001
0x000020e4 in _start ()
(gdb) si
0x000020e8 in _start ()
(gdb)
A bug was added there by Nick Clifton last year when he did some memory
allocation cleanups in cgen_lookup_insn(). It seems not much code uses
this so perhaps it was not noticed.
Also, it looks like you didnt write it, you just imported the original
source?
I have now pushed the fix to my repo. At the same time pushing to
gdb-patches list.
-Stafford
> 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
>
