gdb for egcs/sh-elf

gdb for egcs/sh-elf

[Ralf Corsepius]

Hi,

I am having trouble to remotely debug egcs-applications for an embedded
sh-elf target.

The symtoms are:

I can compile/link the application and successfully download it to the target.

But if trying to debug things are going to be strange: gdb doesn't seem
to find the correct location of functions.

Here is only an excerpt of some observations during a debug session:

1)  Setting a break point

> (gdb) >br bsp_start
> Breakpoint 1 at 0xa0484ea

According to the disassembled code this isn't the address of the
function but at some small offset close beside it.
> 0a0484e8 <_bsp_start>:
> a0484e8:       2f 86           mov.l   r8,@-r15
> a0484ea:       d1 34           mov.l   a0485bc <_bsp_start+0xd4>,r1
! 0xa04
> a0484ec:       2f 96           mov.l   r9,@-r15

2) Setting another break point:

> (gdb) br bsp_cleanup
> Breakpoint 2 at 0xa0484b0:file
/users/corsepiu/src/rtems/corsepiu/rtems/c/src/lib/libbsp/sh/amos/startup/../../shared/main.c,
line 42.

This time this is a complete false location, not even related to this
function.
> 0a0484b0 <_set_vector>:
> a0484b0:       62 43           mov     r4,r2
> a0484b2:       2f e6           mov.l   r14,@-r15
> a0484b4:       64 53           mov     r5,r4

3) After starting the program anything crashes and no breakpoint was
trapped.

> (gdb) c
> Continuing.
>
> Program received signal SIGEMT, Emulation trap.
> 0xffffffff in ?? ()

I am completely unsure where to start to search for the cause of my
problems.

Is it my linker script, the debugging stub on the target, binutils, egcs
or gdb ?

Any help appreciated.

Ralf.

PS.:
I am using gdb-4.16/gdb-971127, egcs-1.0.1, binutils-2.8.1.0.18,
newlib-1.8.0;
The application is pure c, no c++ involved.

Re: gdb for egcs/sh-elf

[Stephen Williams]

corsepiu@faw.uni-ulm.de said:
> I am having trouble to remotely debug egcs-applications for an
> embedded sh-elf target. 

hey, I'm having the same problem with an ii960-coff target. Hmm.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: gdb for egcs/sh-elf

[Jeffrey A Law]

  In message < 34BCDD3E.85DA8B14@faw.uni-ulm.de >you write:
  > Here is only an excerpt of some observations during a debug session:
  > 
  > 1)  Setting a break point
  > 
  > > (gdb) >br bsp_start
  > > Breakpoint 1 at 0xa0484ea
  > 
  > According to the disassembled code this isn't the address of the
  > function but at some small offset close beside it.
  > > 0a0484e8 <_bsp_start>:
  > > a0484e8:       2f 86           mov.l   r8,@-r15
  > > a0484ea:       d1 34           mov.l   a0485bc <_bsp_start+0xd4>,r1
  > ! 0xa04
  > > a0484ec:       2f 96           mov.l   r9,@-r15
This is normal - when setting a breakpoint gdb will try to set it
at the first instruction beyond the prologue.


  > 2) Setting another break point:
  > 
  > > (gdb) br bsp_cleanup
  > > Breakpoint 2 at 0xa0484b0:file
  > /users/corsepiu/src/rtems/corsepiu/rtems/c/src/lib/libbsp/sh/amos/startup/.
  > ./../shared/main.c,
  > line 42.
  > 
  > This time this is a complete false location, not even related to this
  > function.
  > > 0a0484b0 <_set_vector>:
  > > a0484b0:       62 43           mov     r4,r2
  > > a0484b2:       2f e6           mov.l   r14,@-r15
  > > a0484b4:       64 53           mov     r5,r4
According to "nm" what is the value of "bsp_cleanup"?  Is it immediately
before _set_vector?  Might be skip_prologue not stopping when it should
at the end of a function.

  > 3) After starting the program anything crashes and no breakpoint was
  > trapped.
This sounds more like a problem with gdb, your stub, your application
or something else.

jeff

Re: gdb for egcs/sh-elf

[amylaar]

> 1)  Setting a break point
> 
> > (gdb) >br bsp_start
> > Breakpoint 1 at 0xa0484ea
> 
> According to the disassembled code this isn't the address of the
> function but at some small offset close beside it.
> > 0a0484e8 <_bsp_start>:
> > a0484e8:       2f 86           mov.l   r8,@-r15
> > a0484ea:       d1 34           mov.l   a0485bc <_bsp_start+0xd4>,r1

That's a feature.  The breakpoint is set at location after the prologue.

Re: gdb for egcs/sh-elf

[Robert Lipe]

> I am having trouble to remotely debug egcs-applications for an embedded
> sh-elf target.

I don't know if egcs or the gdb list is really the best place for this.

> But if trying to debug things are going to be strange: gdb doesn't seem
> to find the correct location of functions.

Here are some helpful hints for finding it:
gdb foo.out
target sim
load
info addr main
info line main

Compare the outputs of those last two lines with what you think is
happening.    It's not impossible at all for the debugging information
to get hosed in zero or more of the compiler, assembler, linker, linker
scripts, and debugger.   Of course, if your code is relocating itself
in the target, then you have that whole offset query thing to deal with.

Walk down the food chain and manually check one known address.  Do a
gcc -S.   Look at the assembler output.   Do the line numbers make
sense?   Depending on the debug format you use, reading the debug
varies in ease.   If the compiler output looks right, do an objdump
--disassemble --debugging --line-numbers on the .o and see if the 
assembler's line number information looks right.   Keep walking down
the line of tools and generated/grokked files.

> I am using gdb-4.16/gdb-971127, egcs-1.0.1, binutils-2.8.1.0.18,
> newlib-1.8.0;

Welcome to the bleeding edge. :-)

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com