gdb for AT91SAM7

gdb for AT91SAM7

[Roman Mashak]

Hello.

My question concerns to debugging of embedded code on AT91SAM7
targets. Briefly about the background of the problem:
1) I'm using gdb-6.8.50.20080308-cvs
2) toolchain is based on gcc-4.2.2 for Windows
3) JTAG is by Segger, they also provide GDB server

What I'm trying to do is to debug step-by-step the C-startup, written
in ARM assembly language in order to clearly understand the process of
chip initialization, peripheral setup and other low-level stuffs.

I compiled C-startup and my simple application (printing string out of
the USRT), with "-gdwarf-2 -O0" options as recommended. Then I run
gdb, attach to the target. Since the application is linked to 0x100000
I set breakpoint on this address:

#arm-elf-gdb main.elf
#target remote localhost:2331
#break *0x100000
#continue
Continuing.
...

At this point it hangs and doesn't step over. But if I do "jump
*0x100000" right after setting up the breakpoint, it works! This is
kind of strange, isn't it?

Are there any explanations to this? Or such behavior is rather sane?
Thank you in advance for your comments!

-- 
Roman

Re: gdb for AT91SAM7

[Daniel Jacobowitz]

On Wed, May 14, 2008 at 12:42:46AM -0700, Roman Mashak wrote:
> #arm-elf-gdb main.elf
> #target remote localhost:2331
> #break *0x100000
> #continue
> Continuing.
> ...

Is the application already loaded or in flash?  And is the PC already
pointing at 0x100000?  You have to get it pointing to there somehow.

If the PC is already 0x100000 when you say continue, GDB assumes
you're trying to continue, not stop at the current location.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb for AT91SAM7

[Michael Snyder]

On Wed, 2008-05-14 at 00:42 -0700, Roman Mashak wrote:
> Hello.
> 
> My question concerns to debugging of embedded code on AT91SAM7
> targets. Briefly about the background of the problem:
> 1) I'm using gdb-6.8.50.20080308-cvs
> 2) toolchain is based on gcc-4.2.2 for Windows
> 3) JTAG is by Segger, they also provide GDB server
> 
> What I'm trying to do is to debug step-by-step the C-startup, written
> in ARM assembly language in order to clearly understand the process of
> chip initialization, peripheral setup and other low-level stuffs.
> 
> I compiled C-startup and my simple application (printing string out of
> the USRT), with "-gdwarf-2 -O0" options as recommended. Then I run
> gdb, attach to the target. Since the application is linked to 0x100000
> I set breakpoint on this address:

When you say the application is linked to 0x100000, 
do you mean that that is the start address?

> #arm-elf-gdb main.elf
> #target remote localhost:2331
> #break *0x100000
> #continue
> Continuing.
> ...
> 
> At this point it hangs and doesn't step over. But if I do "jump
> *0x100000" right after setting up the breakpoint, it works! This is
> kind of strange, isn't it?

Before you say "continue", or "jump *0x100000", if you 
ask gdb for the current instruction pointer (presumably
"info reg pc"), what does it say?

I've had somewhat similar problems in the past.  The
start address is special in many ways, and so is the 
whole start-up process.

Can you try setting your breakpoint at the 2nd or 3rd
instruction after the start address?

Re: gdb for AT91SAM7

[Roman Mashak]

Hello.

thanks for feedback.

2008/5/14 Daniel Jacobowitz <drow@false.org>:
> On Wed, May 14, 2008 at 12:42:46AM -0700, Roman Mashak wrote:
>> #arm-elf-gdb main.elf
>> #target remote localhost:2331
>> #break *0x100000
>> #continue
>> Continuing.
>> ...
>
> Is the application already loaded or in flash?  And is the PC already
> pointing at 0x100000?  You have to get it pointing to there somehow.

The application is in flash before GDB runs. I checked PC value right
after GDB has started and it's not 0x100000, it varies with every
start, for example 0x10009a0, next it's 0x0.

Should I set PC value in the .gdbinit:

set $pc = 0x100000

>
> If the PC is already 0x100000 when you say continue, GDB assumes
> you're trying to continue, not stop at the current location.
>

-- 
Roman