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



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