Re: [arm-gnu] debugging EABI-kernel with BDI2000/gdb
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [arm-gnu] debugging EABI-kernel with BDI2000/gdb
- To: arm-gnu@xxxxxxxxxxxxxxxx, schindele@xxxxxxxxx
- Subject: Re: [arm-gnu] debugging EABI-kernel with BDI2000/gdb
- From: Paul Brook <paul@xxxxxxxxxxxxxxxx>
- Date: Wed, 4 Jan 2006 16:08:17 +0000
On Wednesday 04 January 2006 15:53, Juergen Schindele wrote:
> Hello guys,
> i tried to debug a 2.6.15 kernel (sooo fresh)
> on a custom PXA270 board with CONFIG_EABI and CONFIG_OABI_COMPAT
> Without BDI2000 / gdb the kernel works fine ;-)
> But when i try to debug it fails when booting from HD.
> Also i have a strange error message from gdb.
> Even without using gdb (only connect/run with BDI2000) it does not boot.
> ANY hints are welcome.
>
> COMMANDS:
> ---------------------------------------------------------------------------
>-----------------
>
> > arm-none-linux-gnueabi-gdb vmlinux
>
> GNU gdb 6.3.50.20050325-cvs
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are welcome to change it and/or distribute copies of it under certain
> conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=arm-none-linux-gnueabi"...
> (gdb) target remote xxx.yyy.zzz.113:2001
> Remote debugging using xxx.yyy.zzz.113:2001
> 0xffff0018 in ?? ()
> warning: shared library handler failed to enable breakpoint
This warning is because you're using a linux targeted gdb. As such it expects
to be debugging a linux application (via gdbserver), and tries to set
breakpoints on the shared library load/unload hooks. The kernel isn't a
normal linux application, so these hooks don't exist.
> (gdb) c
Does execution continue indefinitely here? 0xffff0018 is the IRC exception
vector, so I'd expect this to trigger repeatedly. During normal operation
linux will generate a large number of exceptions, especially once it enters
userspace (which is where your log ends).
The other explanation is that something is getting corrupted by the BDI unit
trapping the exception. This could be registers not getting restored properly
on resume, or something timing related. I don't have access to a DBI2000 unit
so this is all guesswork.
Paul