When something goes wrong, BDI and GDB are a powerful combo. Here are a few landmarks to make them live together in order to get you out of the pit.
Here I assume you've correcly set up your BDI with a workable config.file (ex. elite bdi config). I'll assume when debugging kernel, that you've had your kernel set up with CONFIG_DEBUG_KERNEL and since using BDI also set up with CONFIG_BDI_SWITCH.

Do not configure KGDB support into the kernel along with BDI support, theses are mutually exclusive !

If that is right so far, let's proceed. First, get ready with a three terminals displays on your screen, one with minicom (target view), second with your telnet session to access BDI-monitor (monitor view), third with GDB debugging session (gdb view). Second when your minicom will be set, check you're linked up with BDI device (Here BDI is at 192.168.0.225), and check-stop your target :

$telnet 192.168.0.225
Trying 192.168.0.225...
Connected to 192.168.0.225.
Escape character is '^]'.
BDI Debugger for Embedded PowerPC
=================================
[...]
Elite>reset halt
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x00000001 => 0x00000001
- JTAG exists check passed
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- Target PVR is 0x80822014
- Target SVR is 0x00000000
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- Waiting for target stop passed
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
Elite>

First get the gdb invocation right for your target make use of --host and --target if necessary :

$ ${CROSS_COMPILE}gdb
GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24)
Copyright 2003 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=powerpc-hardhat-linux".
(gdb)

You can simply check if it is right for your target via states above. From here you control all of your target but remember BDI monitor (monitor view) supersedes GDB context (gdb view). Second remember to feed GDB with a executable file, either upon GDB invocation type ${CROSS_COMPILE}gdb vmlinux to debug the kernel, either in GDB monitor type file vmlinux with executable file you want to debug.

What's the goal ? Yes, umm... for example, if you want to debug a module behavior when inserting a pcmcia card, get your target reach linux prompt (target view) and before insertion stop BDI (BDI view) manually. Then you need to know where to put your breakpoint in the module. Upon reboots, addresses may changes for the same symbol because modules lives where kernel tells them to depending to other resources allocations.

If you experience problems to break at a precise location, try to lower number of breakpoint, try to specify mon break hard.
Remember don't specify new breakpoints when running, also usually don't break on function, variables, macros declarations.

In order to debug a module (for example serial_cs module), we need to instruct module insertion to display symbol map at present time and to retrieve text segment address to set a breakpoint. So on the target view side, insmod with mapping option enabled :

$insmod -m serial_cs >serial_cs.map
$grep .text serial_cs.map
.text 00001a54 c3116060 2**2
c3116060 T __insmod_serial_cs_S.text_L6740
c3116060 t .text
$

And on the gdb view side you'll have feed it in with serial_cs symbols from text segment's start address :

(gdb) file linux-2.4.20_mvl31/vmlinux
Reading symbols from linux-2.4.20_mvl31/vmlinux...done.
(gdb) add-symbol-file solutions/pcmcia-cs-3.2.8/clients/serial_cs.o 0xc3116060
add symbol table from file "solutions/pcmcia-cs-3.2.8/clients/serial_cs.o" at
.text_addr = 0xc3116060
(y or n) y
Reading symbols from solutions/pcmcia-cs-3.2.8/clients/serial_cs.o...done.

Also when debugging kernel functions refer to System.map to find your function to debug along with its address. Okay now we can specify a breakpoint in GDB. But you'll have to halt in kernel after MMU is set up via a BDI breakpoint. Upon halting, you could actually link your GDB session up with the BDI device in order to enable GDB to take control over program sequence. In order in BDI monitor view, place a post-MMU init breakpoint (or you could halt running kernel manually). Usually a good place to put it is after kernel start_here symbol at identify_cpu symbol. Get its address in kernel's System.map.

bi 0xc0005eb4
reset run

When breakpoint is triggered and program put to an halt, in gdb view issue link command and proceed :

target remote 192.168.0.225:2001
continue

Remember it's a module debugging thus you'll have to retrieve a symbol name you want to break at. Also as module initialisation seems a good starting point it is not. We've already insmoded it therefore init_serial_cs won't be called anymore. You need to determin another good break. For instance I have a problem with serial configuration. On target view :

cat serial_cs.map | grep config
c3124f80 t multi_config
c312486c t simple_config
c31243b0 t serial_config

On gdb view :

b simple_config
Breakpoint 2 at 0xc312486c

November the 23, 2024

Last udpated on 28 Oct 07