Unable to step over functions in arm-elf binary

Unable to step over functions in arm-elf binary

[Colin MacDonald]

We have .elf targets for Arm processors and we can debug these via a remote connection (using the remote serial protocol) with Insight / GDB.  Everything works fine except for one thing: I can't step over a function.  If I try to step over a function I invariably step into it instead.  Using the 'n' command from GDB command line generates a sequence remote serial commands like this:

1. A breakpoint is set with $Z, but it's a breakpoint that I already have in the code
2. A series of $s and $p commands, step then check register, are executed, presumably hunting for the desired program counter value
3. Once the PC reaches the appropriate number I see a $m, probably to get a local variable value or something of the sort.
4. The breakpoint set in 1 is cleared with $z.

I was expecting that a breakpoint would be set temporarily at the next line of code then a $c (continue) would be issued.

Is this a known problem?  Does it only affect Arm targets, or is it only a problem using the remote serial protocol?  Any clues gratefully appreciated.

Colin MacDonald





		
____________________________________________________ 
 
Yahoo! Photos is now offering a quality print service from just 7p a photo. http://uk.photos.yahoo.com

Re: Unable to step over functions in arm-elf binary

[Daniel Jacobowitz]

On Thu, Feb 22, 2007 at 11:48:53AM +0000, Colin MacDonald wrote:
> We have .elf targets for Arm processors and we can debug these via a remote connection (using the remote serial protocol) with Insight / GDB.  Everything works fine except for one thing: I can't step over a function.  If I try to step over a function I invariably step into it instead.  Using the 'n' command from GDB command line generates a sequence remote serial commands like this:

You didn't say what version of GDB you're using.  Try a newer one?  It
sounds like yours fails to backtrace after stepping in to a function.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Unable to step over functions in arm-elf binary

[Colin MacDonald]

I'm using GDB / Insight 6.5.  First attempts with 6.6 appear to show the same behaviour.

I updated my remote serial server to support $vCont packets as well as the basic $c and $s packets but no joy.

Colin MacDonald

----- Original Message ----
From: Daniel Jacobowitz <drow@false.org>
To: Colin MacDonald <colin_mac2002@yahoo.co.uk>
Cc: gdb@sourceware.org
Sent: Thursday, 22 February, 2007 12:27:23 PM
Subject: Re: Unable to step over functions in arm-elf binary

On Thu, Feb 22, 2007 at 11:48:53AM +0000, Colin MacDonald wrote:
> We have .elf targets for Arm processors and we can debug these via a remote connection (using the remote serial protocol) with Insight / GDB.  Everything works fine except for one thing: I can't step over a function.  If I try to step over a function I invariably step into it instead.  Using the 'n' command from GDB command line generates a sequence remote serial commands like this:

You didn't say what version of GDB you're using.  Try a newer one?  It
sounds like yours fails to backtrace after stepping in to a function.


-- 
Daniel Jacobowitz
CodeSourcery





		
___________________________________________________________ 
All New Yahoo! Mail – Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

Re: Unable to step over functions in arm-elf binary

[Daniel Jacobowitz]

On Thu, Feb 22, 2007 at 12:56:04PM +0000, Colin MacDonald wrote:
> I'm using GDB / Insight 6.5.  First attempts with 6.6 appear to show the same behaviour.
> 
> I updated my remote serial server to support $vCont packets as well as the basic $c and $s packets but no joy.

I recommend you single step (using stepi) to the first instruction of
a function you can't "next" over, and try "backtrace".  If it's wrong,
that's your problem.  Keep stepi'ing a bit until you're into the
function body.

Another thing that may be helpful is "set debug infrun 1".


-- 
Daniel Jacobowitz
CodeSourcery

Re: Unable to step over functions in arm-elf binary

[Colin MacDonald]

OK, so I have a breakpoint on a line that calls a function.  When I hit the breakpoint the backtrace shows this:

#0  CPlatform::RunTestSuite (this=0x207ffb4) at Common/Platform.cpp:113
#1  0x01017db0 in main (argc=17253984, argv=0x0) at OtherFiles/Main.cpp:37

This is fine so far.  Line 113 of platform.cpp calls a function called vs_status.  If I stepi until I first hit vs_status I get the following as the backtrace:

#0  vs_status (pInBuf=0x0) at Common/PlatformIO.cpp:149
#1  0x00000000 in ?? ()

Doesn't look happy.  If I execute another stepi then pInBuf is picked up.  Another few stepi instructions then fills in the backtrace properly:

#0  vs_status (pInBuf=0x207ffb4 "Ôé\006\001\224Ù\006\001ØV\a\001¬\r")
    at Common/PlatformIO.cpp:153
#1  0x010034f8 in CPlatform::RunTestSuite (this=0x207ffb4)
    at Common/Platform.cpp:113
#2  0x01017db0 in main (argc=17253984, argv=0x0) at OtherFiles/Main.cpp:37

which seems fine.

The code in the region of line 2401 in infrun.c:

  if (!frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id)
      && frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id))
    {

should
determine whether or not we have stepped into a subroutine and, if so,
will go on to set a breakpoint at the caller's location in the desired
way.  The frame_id_eq call is returning zero, however, so I don't get
the breakpoint.  With frame debug on I get a pile of stuff the
culminates in:

{ frame_id_eq (l={!stack,!code,!special},r={stack=0x207ff68,code=0x10032dc,!special}) -> 0 }

which
makes me think that get_current_frame is returning something
unexpected.  Certainly if I bypass the above test then I get a failure
assertion in
    insert_step_resume_breakpoint_at_caller (get_current_frame ());

I've tried building with -mapcs-frame but it doesn't seem to make any difference.  And that's me into guesswork now.

Colin MacDonald


----- Original Message ----
From: Daniel Jacobowitz <drow@false.org>
To: Colin MacDonald <colin_mac2002@yahoo.co.uk>
Cc: gdb@sourceware.org
Sent: Thursday, 22 February, 2007 1:12:59 PM
Subject: Re: Unable to step over functions in arm-elf binary

On Thu, Feb 22, 2007 at 12:56:04PM +0000, Colin MacDonald wrote:
> I'm using GDB / Insight 6.5.  First attempts with 6.6 appear to show the same behaviour.
> 
> I updated my remote serial server to support $vCont packets as well as the basic $c and $s packets but no joy.

I recommend you single step (using stepi) to the first instruction of
a function you can't "next" over, and try "backtrace".  If it's wrong,
that's your problem.  Keep stepi'ing a bit until you're into the
function body.

Another thing that may be helpful is "set debug infrun 1".


-- 
Daniel Jacobowitz
CodeSourcery





	
	
		
___________________________________________________________ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Re: Unable to step over functions in arm-elf binary

[Daniel Jacobowitz]

On Thu, Feb 22, 2007 at 04:55:55PM +0000, Colin MacDonald wrote:
> OK, so I have a breakpoint on a line that calls a function.  When I hit the breakpoint the backtrace shows this:
> 
> #0  CPlatform::RunTestSuite (this=0x207ffb4) at Common/Platform.cpp:113
> #1  0x01017db0 in main (argc=17253984, argv=0x0) at OtherFiles/Main.cpp:37
> 
> This is fine so far.  Line 113 of platform.cpp calls a function called vs_status.  If I stepi until I first hit vs_status I get the following as the backtrace:
> 
> #0  vs_status (pInBuf=0x0) at Common/PlatformIO.cpp:149
> #1  0x00000000 in ?? ()
> 
> Doesn't look happy.  If I execute another stepi then pInBuf is picked up.  Another few stepi instructions then fills in the backtrace properly:

That's the bug, and nowhere else.  You need to find out why it can't
unwind.  Is your compiler emitting sufficiently bogus debug info that
GDB is confused?  Or have some symbols been unexpectedly stripped from
the ELF file?  Those are the usual culprits.


-- 
Daniel Jacobowitz
CodeSourcery