tracking "next" failure?

tracking "next" failure?

[Richard Henderson]

How in the world do you go about finding out why:

   Breakpoint 1, main () at .../testsuite/gdb.base/all-types.c:35
   35          dummy();
   (gdb) next

   Program exited normally.
   (gdb) FAIL: gdb.base/all-bin.exp: continuing after dummy()

loses control of the application?  I'm getting completely lost.

I suspect that this is responsible for the bulk of the gdb test
failures on alpha at the moment.


r~

Re: tracking "next" failure?

[Andrew Cagney]

> How in the world do you go about finding out why:
> 
>    Breakpoint 1, main () at .../testsuite/gdb.base/all-types.c:35
>    35          dummy();
>    (gdb) next
> 
>    Program exited normally.
>    (gdb) FAIL: gdb.base/all-bin.exp: continuing after dummy()
> 
> loses control of the application?  I'm getting completely lost.
> 
> I suspect that this is responsible for the bulk of the gdb test
> failures on alpha at the moment.

Set a breakpoint on *_saved_pc_after_call, and then use nexti.

The loss of control is likely from a dud return address (used for 
setting the return breakpoint) being computed when the the code is first 
stepped into dummy().  The other is (hmm, alpha) something going wrong 
with software single step?

Andrew

[RFA] fix dwarf2 unwind of pc

[Richard Henderson]

On Sat, May 31, 2003 at 10:48:01PM -0400, Andrew Cagney wrote:
> The loss of control is likely from a dud return address (used for 
> setting the return breakpoint) being computed when the the code is first 
> stepped into dummy().

Indeed, a problem with the new dwarf2 unwinder.  Neither of the
targets Mark tested have the return address in a register.  Ok?


r~



	* dwarf2-frame.c (dwarf2_frame_cache): Handle retaddr_column
	not overlapping PC_REGNUM.

Index: dwarf2-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2-frame.c,v
retrieving revision 1.1
diff -c -p -d -r1.1 dwarf2-frame.c
*** dwarf2-frame.c	31 May 2003 19:18:05 -0000	1.1
--- dwarf2-frame.c	1 Jun 2003 04:26:17 -0000
*************** dwarf2_frame_cache (struct frame_info *n
*** 550,558 ****
  	cache->reg[regnum] = fs->regs.reg[reg];
      }
  
!   /* Stored the location of the return addess.  */
!   if (fs->retaddr_column < fs->regs.num_regs)
      cache->reg[PC_REGNUM] = fs->regs.reg[fs->retaddr_column];
  
    do_cleanups (old_chain);
  
--- 550,570 ----
  	cache->reg[regnum] = fs->regs.reg[reg];
      }
  
!   /* Store the location of the return addess.  If the return address
!      column (adjusted) is not the same as gdb's PC_REGNUM, then this
!      implies a copy from the ra column register.  */
!   if (fs->retaddr_column < fs->regs.num_regs
!       && fs->regs.reg[fs->retaddr_column].how != REG_UNSAVED)
      cache->reg[PC_REGNUM] = fs->regs.reg[fs->retaddr_column];
+   else
+     {
+       reg = DWARF2_REG_TO_REGNUM (fs->retaddr_column);
+       if (reg != PC_REGNUM)
+ 	{
+ 	  cache->reg[PC_REGNUM].loc.reg = reg;
+ 	  cache->reg[PC_REGNUM].how = REG_SAVED_REG;
+ 	}
+     }
  
    do_cleanups (old_chain);
  

Re: [RFA] fix dwarf2 unwind of pc

[Mark Kettenis]

Richard Henderson <rth@redhat.com> writes:

> On Sat, May 31, 2003 at 10:48:01PM -0400, Andrew Cagney wrote:
> > The loss of control is likely from a dud return address (used for 
> > setting the return breakpoint) being computed when the the code is first 
> > stepped into dummy().
> 
> Indeed, a problem with the new dwarf2 unwinder.  Neither of the
> targets Mark tested have the return address in a register.  Ok?
> 
> r~
> 
> 	* dwarf2-frame.c (dwarf2_frame_cache): Handle retaddr_column
> 	not overlapping PC_REGNUM.

Ah, GCC is trying to be economical here.  From reading the DWARF
standard I would have expected the compiler to have emitted CFA
instructions that actually put something in the return address column.
Anyway, this shouldn't hurt.

Approved.

Mark