bdi2000 and gdb (newbie question)

bdi2000 and gdb (newbie question)

[Mark Beckwith]

I've got a bdi2000 and Cogent csb337 running the micromonitor boot loader.
I've been able to compile and download the umon to the csb337 successfully
using the bdi2000 and jtag interface.  

However, I can't seem to step through the code.  I 

After loading the CSB337_tst.elf file into ram, from the host I run:

prompt> gdb CSB337_tst.elf 

(gdb) target remote 192.168.100.44:2001
Remote debugging using 192.168.100.44:2001
0x00000000 in ?? ()

// Ok, then I try to step:

(gdb) step  
Cannot find bounds of current function

// I can set breakpoints:

(gdb) b main
Breakpoint 1 at 0x2011beac: file main.c, line 45.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x63655220 in ?? ()
(gdb) step
Cannot find bounds of current function

I hope you can see something obvious that I'm doing wrong, and point me in
the right direction.

Thanks,

Mark

-- 
Mark Beckwith, Intrig (http://www.intrig.com)

Re: bdi2000 and gdb (newbie question)

[Daniel Jacobowitz]

On Thu, Aug 26, 2004 at 03:57:15PM -0500, Mark Beckwith wrote:
> I've got a bdi2000 and Cogent csb337 running the micromonitor boot loader.
> I've been able to compile and download the umon to the csb337 successfully
> using the bdi2000 and jtag interface.  

A list for your target is more likely to help; this is some interaction
between your JTAG device, target (which I've never heard of),
bootloader (which I've never heard of), et cetera.

-- 
Daniel Jacobowitz

Re: bdi2000 and gdb (newbie question)

[Jay Monkman]

On Thu, Aug 26, 2004 at 03:57:15PM -0500, Mark Beckwith wrote:
> prompt> gdb CSB337_tst.elf 
> 
> (gdb) target remote 192.168.100.44:2001
> Remote debugging using 192.168.100.44:2001
> 0x00000000 in ?? ()
> 
> // Ok, then I try to step:
> 
> (gdb) step  
> Cannot find bounds of current function

It doesn't look like you loaded your program. Here's the basic
sequence I use 

# gdb

(gdb) file whatever.elf
(gdb) load
(gdb) br main
(gdb) continue

There are a few things to keep in mind when using the BDI-2000 with
GDB. 
 - You need to load the file before you do start trying to run it.
 - Use 'continue' not 'run' to initiate execution.
 - Make sure you have the BDI-2000 configured for the correct 
   type of breakpoints.
 - (ARM specific) It is frequently good to put break points at the
    data and instruction expection vectors:
      br *0xc
      br *0x10

Re: bdi2000 and gdb (newbie question)

[Fabian Cenedese]

>I've got a bdi2000 and Cogent csb337 running the micromonitor boot loader.
>I've been able to compile and download the umon to the csb337 successfully
>using the bdi2000 and jtag interface.  
>
>prompt> gdb CSB337_tst.elf 
>
>(gdb) target remote 192.168.100.44:2001
>Remote debugging using 192.168.100.44:2001
>0x00000000 in ?? ()

snip

>Program received signal SIGTRAP, Trace/breakpoint trap.
>0x63655220 in ?? ()
>(gdb) step
>Cannot find bounds of current function

I don't know this target. But you should look at what data gets returned
over the remote interface (was that "set debug remote 1"?). I also had
similar effects when I returned wrong data for the registers in my self
written stub. Another thing to look at is the endianess. I work with PPC
which can be both little and big endian. Maybe you need to set it
("set endian big/lttle/auto").

BTW, 0x63655220 is "ceR " in ASCII or " Rec" if you change order.
Maybe this looks familiar? I think some string is interpreted as value
for the register (Ok, I know that the remote protocol is MADE of
strings :).

bye  Fabi

Re: bdi2000 and gdb (newbie question)

[Mark Beckwith]

On Thu, Aug 26, 2004 at 05:17:13PM -0500, Jay Monkman wrote:
> On Thu, Aug 26, 2004 at 03:57:15PM -0500, Mark Beckwith wrote:
> > prompt> gdb CSB337_tst.elf 
> > 
> > (gdb) target remote 192.168.100.44:2001
> > Remote debugging using 192.168.100.44:2001
> > 0x00000000 in ?? ()
> > 
> > // Ok, then I try to step:
> > 
> > (gdb) step  
> > Cannot find bounds of current function
> 
> It doesn't look like you loaded your program. Here's the basic
> sequence I use 
> 
> # gdb
> 
> (gdb) file whatever.elf
> (gdb) load
> (gdb) br main
> (gdb) continue

Ok, thanks for the tip on the load comand.  Here is the sequence I use now.
I've inserted comments with //

# gdb
(gdb) file CSB337_tst.elf
Reading symbols from CSB337_tst.elf...done.
(gdb) target remote 192.168.1.93:2001
Remote debugging using 192.168.1.93:2001
0xffffffff in ?? ()
(gdb) load
Loading section .text, size 0x1dad4 lma 0x20100000
Loading section .data, size 0x12dc lma 0x2011dad4
Loading section .rodata, size 0x6596 lma 0x2011edb0
Start address 0x20100070, load size 152390
Transfer rate: 152390 bits/sec, 299 bytes/write.
(gdb) br main
Note: breakpoint -2 also set at pc 0x2011beac. // don't know where this came from
Breakpoint 1 at 0x2011beac: file main.c, line 45.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
<function called from gdb>
Current language:  auto; currently asm
(gdb) next
    // here, there is a very long pause here, then:
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0xdead: Unknown error 4294967295.
    // the bdi console also outputs:
# TARGET: all hardware breakpoints in use

So it looks like my breakpoint setup is incorrect, right?   I have the BDI
configured for HARD breakpoints.  Is there something else I need to do?  

Also, if I don't insert a breakpoint, and then just type continue, and hit
control-c a few seconds later I get:

(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00000000 in ?? ()

My endianness is set to LITTLE.  

Thanks,

Mark

> 
> There are a few things to keep in mind when using the BDI-2000 with
> GDB. 
>  - You need to load the file before you do start trying to run it.
>  - Use 'continue' not 'run' to initiate execution.
>  - Make sure you have the BDI-2000 configured for the correct 
>    type of breakpoints.
>  - (ARM specific) It is frequently good to put break points at the
>     data and instruction expection vectors:
>       br *0xc
>       br *0x10

-- 
Mark Beckwith, Intrig (http://www.intrig.com)

Re: bdi2000 and gdb (newbie question)

[Jay Monkman]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

On Fri, Aug 27, 2004 at 11:24:07AM -0500, Mark Beckwith wrote:
> (gdb) br main
> Note: breakpoint -2 also set at pc 0x2011beac. // don't know where this came from
> Breakpoint 1 at 0x2011beac: file main.c, line 45.

That seems odd. Maybe it's an artifact of using HW breakpoints, but I
don't think so.

> Program received signal SIGTRAP, Trace/breakpoint trap.
> <function called from gdb>

What is the PC when you get here? (It will probably be off by 8 bytes
from the next instruction to be executed.) My guess is that the CPU
ended up running through the weeds.

It looks like you have a problem in your program between your entry
point (0x20110070) and main(). Maybe instead of putting your break
point at main(), put it earlier or even start single-stepping from
your program's entry point.

Are you running from RAM or some kind of ROM? If you are running from
RAM, you'll probably be better off using SW breakpoints. Since the
ARM920 only has 1 HW breakpoint, it limits your ability to debug.

Based on the addressess, it looks like you are running from SDRAM. Are
you initializing it before loading the program (like in the BDI-2000's
config file)?





> Current language:  auto; currently asm
> (gdb) next
>     // here, there is a very long pause here, then:
> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0xdead: Unknown error 4294967295.
>     // the bdi console also outputs:
> # TARGET: all hardware breakpoints in use

This is because you've got a breakpoint at main() and using 'next'
causes gdb to insert a breakpoint for the next line of code. The
ARM920 only has one HW breakpoint, and you are trying to use two.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: bdi2000 and gdb (newbie question)

[Mark Beckwith]

Thanks for your help.  I  realized that something was very wrong with my
setup.  Turns out I had to recompile gdb with the configure option
"--target=arm-linux".   I guess this is one of the things that I was just
supposed to know.  Still, it would be nice to get a "target not supported"
error when I do the "target remote" command.   Would this be possible?  If
so I would like to volunteer.

So I'm debugging just fine now out of ram.   However, when I set BREAKMODE
HARD and try to step through flash, only one breakpoint gets hit, and then
can't step or set another.  The documentation I've read states that the
breakpoint will be cleared once it is hit, but that doesn't seem to be
happening.  Also the delete command doesn't seem to clear the hardware
breakpoint.  I have to do a "ci" all the time from the bdi.  Any
suggestions on working with hardware breakpoints? 

Thanks,

Mark


On Fri, Aug 27, 2004 at 12:54:20PM -0500, Jay Monkman wrote:
> On Fri, Aug 27, 2004 at 11:24:07AM -0500, Mark Beckwith wrote:
> > (gdb) br main
> > Note: breakpoint -2 also set at pc 0x2011beac. // don't know where this came from
> > Breakpoint 1 at 0x2011beac: file main.c, line 45.
> 
> That seems odd. Maybe it's an artifact of using HW breakpoints, but I
> don't think so.
> 
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > <function called from gdb>
> 
> What is the PC when you get here? (It will probably be off by 8 bytes
> from the next instruction to be executed.) My guess is that the CPU
> ended up running through the weeds.
> 
> It looks like you have a problem in your program between your entry
> point (0x20110070) and main(). Maybe instead of putting your break
> point at main(), put it earlier or even start single-stepping from
> your program's entry point.
> 
> Are you running from RAM or some kind of ROM? If you are running from
> RAM, you'll probably be better off using SW breakpoints. Since the
> ARM920 only has 1 HW breakpoint, it limits your ability to debug.
> 
> Based on the addressess, it looks like you are running from SDRAM. Are
> you initializing it before loading the program (like in the BDI-2000's
> config file)?
> 
> 
> 
> 
> 
> > Current language:  auto; currently asm
> > (gdb) next
> >     // here, there is a very long pause here, then:
> > Warning:
> > Cannot insert breakpoint 0.
> > Error accessing memory address 0xdead: Unknown error 4294967295.
> >     // the bdi console also outputs:
> > # TARGET: all hardware breakpoints in use
> 
> This is because you've got a breakpoint at main() and using 'next'
> causes gdb to insert a breakpoint for the next line of code. The
> ARM920 only has one HW breakpoint, and you are trying to use two.
> 



-- 
Mark Beckwith, Intrig (http://www.intrig.com)

Re: bdi2000 and gdb (newbie question)

[Jay Monkman]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Wed, Sep 01, 2004 at 11:18:29AM -0500, Mark Beckwith wrote:
> error when I do the "target remote" command.   Would this be possible?  If
> so I would like to volunteer.

That might be a limitation with the remote protocol. I don't think
there's any info in it declaring the architecture type.


> So I'm debugging just fine now out of ram.   However, when I set BREAKMODE
> HARD and try to step through flash, only one breakpoint gets hit, and then
> can't step or set another.  The documentation I've read states that the
> breakpoint will be cleared once it is hit, but that doesn't seem to be

What documentation? I've never seen it remove the breakpoint
permanently unless I delete it.

> happening.  Also the delete command doesn't seem to clear the hardware
> breakpoint.  I have to do a "ci" all the time from the bdi.  Any
> suggestions on working with hardware breakpoints? 

Did you insert the breakpoint with gdb?

If you are running from RAM, you will probably have better success if
you use soft breakpoints.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: bdi2000 and gdb (newbie question)

[Mark Beckwith]

On Wed, Sep 01, 2004 at 01:57:42PM -0500, Jay Monkman wrote:
> On Wed, Sep 01, 2004 at 11:18:29AM -0500, Mark Beckwith wrote:
> > error when I do the "target remote" command.   Would this be possible?  If
> > so I would like to volunteer.
> 
> That might be a limitation with the remote protocol. I don't think
> there's any info in it declaring the architecture type.
 
> 
> > So I'm debugging just fine now out of ram.   However, when I set BREAKMODE
> > HARD and try to step through flash, only one breakpoint gets hit, and then
> > can't step or set another.  The documentation I've read states that the
> > breakpoint will be cleared once it is hit, but that doesn't seem to be
> 
> What documentation? I've never seen it remove the breakpoint
> permanently unless I delete it.
 
Just something I read somewhere. 

> > happening.  Also the delete command doesn't seem to clear the hardware
> > breakpoint.  I have to do a "ci" all the time from the bdi.  Any
> > suggestions on working with hardware breakpoints? 
> 
> Did you insert the breakpoint with gdb?
 
Yes.

> If you are running from RAM, you will probably have better success if
> you use soft breakpoints.
 
I know.  Problem is I am stepping the through the flash code that is run on
bootup to set up the ram.  

Mark




-- 
Mark Beckwith, Intrig (http://www.intrig.com)