RE: single stepping mips remote programs built with gcc 4.0

RE: single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

> Could you please build a debuggable GDB binary, and trace through
> mips32_next_pc?  It looks like it should handle the 'j' instruction
> just fine:
> 
>         case 2:         /* J */
>         case 3:         /* JAL */
>           {
>             unsigned long reg;
>             reg = jtype_target (inst) << 2;
>             /* Upper four bits get never changed... */
>             pc = reg + ((pc + 4) & 0xf0000000);
>           }
>           break;
> 
> J and JAL share a format, so this should be correct.  It's as if the
> value GDB is extracting for the instruction is incorrect.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 

I built it with the default options, that good enough? Something like
"-g -O2" it seems.

I doubt that mips32_next_pc is getting compiled in because I can set a
breakpoint at mips_next_pc but not mips32_next_pc.  
mips_software_single_step never gets called in this sequence, should it
be? 

Re: single stepping mips remote programs built with gcc 4.0

[Daniel Jacobowitz]

On Thu, Nov 17, 2005 at 02:23:17PM -0800, Newman, Sarah R wrote:
> I built it with the default options, that good enough? Something like
> "-g -O2" it seems.
> 
> I doubt that mips32_next_pc is getting compiled in because I can set a
> breakpoint at mips_next_pc but not mips32_next_pc.  
> mips_software_single_step never gets called in this sequence, should it
> be? 

Could you show me a session transcript?  If mips_software_single_step
isn't placing the breakpoint, what is?

mips32_next_pc was probably inlined; you can retry with -g -O0 if you
want.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

 

> You've talked about GDB inserting breakpoints for software
> single-stepping, but you're not using software single-stepping here. 
> Those memory writes are for your user breakpoints at the entry point
> and exit point of main.  The 's' packet indicates that the stub itself
> is doing the single-stepping.

Which run?  The first run I had a user breakpoint at the very beginning of main, the second run I had the breakpoint one instruction after the beginning.

Run 1:

Num Type           Disp Enb Address    What
1   breakpoint     keep y   0xffffffff80001998 in main at tmp.c:11
2   breakpoint     keep y   0xffffffff800019b0 in main at tmp.c:14

gdb) step
(gdb) p/x $pc
$2 = 0x800019a0

(gdb) set debug remote 1
(gdb) step
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $M80001998,4:0005000d#43...Ack <-- user breakpoint
Packet received: OK
Sending packet: $m800019b0,4#91...Ack
Packet received: 03e00008
Sending packet: $M800019b0,4:0005000d#64...Ack <-- user breakpoint
Packet received: OK
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 800019a4
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 80001990
Sending packet: $p1d#05...Ack
Packet received: 8402ba60
Sending packet: $p1f#07...Ack
Packet received: 800019a8
Sending packet: $m8000199c,4#9b...Ack
Packet received: afbf0010
Sending packet: $m800019a0,4#90...Ack
Packet received: 0c000664   
Sending packet: $m800019a4,4#94...Ack
Packet received: 00000000
Sending packet: $c#63...Ack  

----
Run 2:

Num Type           Disp Enb Address    What
2   breakpoint     keep y   0xffffffff800019b0 in main at tmp.c:14
3   breakpoint     keep y   0xffffffff8000199c in main at tmp.c:11 <-- one instruction later than run 1

Sending packet: $m800019b0,4#91...Ack
Packet received: 03e00008
Sending packet: $M800019b0,4:0005000d#64...Ack <-- user breakpoint
Packet received: OK
Sending packet: $m8000199c,4#9b...Ack
Packet received: afbf0010
Sending packet: $M8000199c,4:0005000d#6e...Ack <-- user breakpoint
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: ENN
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 800019a4
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 80001990
Sending packet: $p1d#05...Ack
Packet received: 8402ba60
Sending packet: $p1f#07...Ack
Packet received: 800019a8
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $m800019a0,4#90...Ack
Packet received: 0c000664
Sending packet: $m800019a4,4#94...Ack
Packet received: 00000000
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $M80001998,4:0005000d#43...Ack <-- not user breakpoint
Packet received: OK
Sending packet: $c#63...Ack
Packet received: S02
Sending packet: $p25#d7...Ack
Packet received: 800019b0

> 
> > Sending packet: $m8000199c,4#9b...Ack
> > Packet received: afbf0010
> > Sending packet: $m800019a0,4#90...Ack
> > Packet received: 0c000664
> > Sending packet: $m800019a4,4#94...Ack
> > Packet received: 00000000
> 
> This is weird.  It looks like GDB is doing some prologue analysis
> here, but it's not starting at any function's entry point.  That,
> combined with the fact that you said that disassembly shows you the
> wrong code, makes me wonder if the debug info is right.
> 
> When you say 'print &a' or 'print &main', do you get the 
> right addresses?
  
Yes, I get the right addresses. When I disassemble the functions in the console I get the right thing too.
But when I use insight to show an assembly listing of a particular function, it shows the function after.  I did not realize that disassembling in the console and showing the assembly of a function with insight could give different results. 

I said something inaccurate before -- I was compiling this program with "-gstabs+" , not "-g".  I have seen different behavior depending on if I use "-g" or "-gstabs+" with some other programs, but I just tried both flags and it doesn't seem to make a difference here.

Re: single stepping mips remote programs built with gcc 4.0

[Jim Blandy]

It might be worth pointing out:

> (gdb) step
> Sending packet: $m80001998,4#70...Ack
> Packet received: 27bdffe8
> Sending packet: $M80001998,4:0005000d#43...Ack
> Packet received: OK
> Sending packet: $m800019b0,4#91...Ack
> Packet received: 03e00008
> Sending packet: $M800019b0,4:0005000d#64...Ack
> Packet received: OK
> Sending packet: $s#73...Ack
> Packet received: S05

You've talked about GDB inserting breakpoints for software
single-stepping, but you're not using software single-stepping here. 
Those memory writes are for your user breakpoints at the entry point
and exit point of main.  The 's' packet indicates that the stub itself
is doing the single-stepping.

> Sending packet: $m8000199c,4#9b...Ack
> Packet received: afbf0010
> Sending packet: $m800019a0,4#90...Ack
> Packet received: 0c000664
> Sending packet: $m800019a4,4#94...Ack
> Packet received: 00000000

This is weird.  It looks like GDB is doing some prologue analysis
here, but it's not starting at any function's entry point.  That,
combined with the fact that you said that disassembly shows you the
wrong code, makes me wonder if the debug info is right.

When you say 'print &a' or 'print &main', do you get the right addresses?

RE: single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

Breakpoint 1, step_into_function (ecs=0x22d810)
    at ../../GDB-ISS/gdb/infrun.c:2646
2646      s = find_pc_symtab (stop_pc);
(gdb) p/x stop_pc
$5 = 0xffffffff80001990
(gdb) next
2647      if (s && s->language != language_asm)
(gdb) p *s
$6 = {next = 0x104c6058, blockvector = 0x104ceb68, linetable =
0x104cebd8,
  block_line_section = 2, primary = 1, macro_table = 0x0,
  filename = 0x104cebc8 "tmp.c", dirname = 0x104cec60 "/tmp/",
  free_code = free_linetable, free_func = 0, nlines = 0, line_charpos =
0x0,
  language = language_c, debugformat = 0x104cec68 "stabs", version =
0x0,
  fullname = 0x1051d0f0 "/tmp/tmp.c", objfile = 0x10411fb8}
(gdb) next
2648        ecs->stop_func_start = SKIP_PROLOGUE (ecs->stop_func_start);
(gdb) p/x ecs->stop_func_start
$7 = 0xffffffff80001990
(gdb) step
gdbarch_skip_prologue (gdbarch=0x103fc470, ip=18446744071562074512)
    at ../../GDB-ISS/gdb/gdbarch.c:2909
2909      gdb_assert (gdbarch != NULL);
(gdb) next
2910      gdb_assert (gdbarch->skip_prologue != NULL);
(gdb)
2911      if (gdbarch_debug >= 2)
(gdb)
2913      return gdbarch->skip_prologue (ip);
(gdb) step
mips_skip_prologue (pc=18446744071562074512)
    at ../../GDB-ISS/gdb/mips-tdep.c:4187
4187      if (find_pc_partial_function (pc, NULL, &func_addr, NULL))
(gdb) next
4189          CORE_ADDR post_prologue_pc = skip_prologue_using_sal
(func_addr);
(gdb) p func_addr
$8 = 18446744071562074512
(gdb) p/x func_addr
$9 = 0xffffffff80001990
(gdb) step
skip_prologue_using_sal (func_addr=18446744071562074512)
    at ../../GDB-ISS/gdb/symtab.c:4027
4027      find_pc_partial_function (func_addr, NULL, &start_pc,
&end_pc);
(gdb) next
4028      start_pc += DEPRECATED_FUNCTION_START_OFFSET;
(gdb) p/x start_pc
$10 = 0xffffffff80001990
(gdb) p/x end_pc
$11 = 0xffffffff80001998
(gdb) next
4030      prologue_sal = find_pc_line (start_pc, 0);
(gdb)
4031      if (prologue_sal.line != 0)
(gdb) p prologue_sal
$12 = {symtab = 0x104ceb80, section = 0x0, line = 8,
  pc = 18446744071562074512, end = 18446744071562074520}
(gdb) p/x prologue_sal
$13 = {symtab = 0x104ceb80, section = 0x0, line = 0x8,
  pc = 0xffffffff80001990, end = 0xffffffff80001998}
(gdb) next
4033          while (prologue_sal.end < end_pc)
(gdb) p/x end_pc
$14 = 0xffffffff80001998
(gdb) next
4054      return prologue_sal.end;
(gdb)
4055    }
(gdb)
mips_skip_prologue (pc=18446744071562074512)
    at ../../GDB-ISS/gdb/mips-tdep.c:4190
4190          if (post_prologue_pc != 0)
(gdb)
4191            return max (pc, post_prologue_pc);
(gdb) p/x pc
$15 = 0xffffffff80001990
(gdb) p/x post_prologue_pc
$16 = 0xffffffff80001998
(gdb) next
4208    }
(gdb)
gdbarch_skip_prologue (gdbarch=0x103fc470, ip=18446744071562074512)
    at ../../GDB-ISS/gdb/gdbarch.c:2914
2914    }
(gdb)
step_into_function (ecs=0x22d810) at ../../GDB-ISS/gdb/infrun.c:2650
2650      ecs->sal = find_pc_line (ecs->stop_func_start, 0);
(gdb) p/x ecs->stop_func_start
$17 = 0xffffffff80001998
(gdb) next
2657      if (ecs->sal.end
(gdb) p/x ecs->sal
$18 = {symtab = 0x104ceb80, section = 0x0, line = 0xb,
  pc = 0xffffffff80001998, end = 0xffffffff800019a0}
(gdb) next
2678      if (gdbarch_adjust_breakpoint_address_p (current_gdbarch))
(gdb) next
2685      if (ecs->stop_func_start == stop_pc)
(gdb) next
2696          init_sal (&sr_sal);       /* initialize to zeroes */
(gdb) next
2697          sr_sal.pc = ecs->stop_func_start;
(gdb) next
2698          sr_sal.section = find_pc_overlay (ecs->stop_func_start);
(gdb) next
2703          insert_step_resume_breakpoint_at_sal (sr_sal,
null_frame_id);
(gdb) p/x sr_sal
$19 = {symtab = 0x0, section = 0x0, line = 0x0, pc = 0xffffffff80001998,
  end = 0x0}

RE: single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

> We realize we've stepped into a function call.  But we're continuing
> without setting any breakpoint at all, which is bogus.
> 
> > #0  remote_resume (ptid={pid = -1, lwp = 0, tid = 0}, step=0,
> >     siggnal=TARGET_SIGNAL_0) at ../../GDB-ISS/gdb/remote.c:2603
> > #1  0x004240bb in resume (step=0, sig=TARGET_SIGNAL_0)
> >     at ../../GDB-ISS/gdb/infrun.c:624
> > #2  0x004278b7 in keep_going (ecs=0x22d810) at
> > ../../GDB-ISS/gdb/infrun.c:2825
> > #3  0x00427606 in step_into_function (ecs=0x22d810)
> >     at ../../GDB-ISS/gdb/infrun.c:2708
> > #4  0x00426d3a in handle_inferior_event (ecs=0x22d810)
> >     at ../../GDB-ISS/gdb/infrun.c:2433
> 
> I can see no way at all for step_into_function to call keep_going
> without inserting a stop breakpoint.  Obviously that's gone wrong.
> Please step through that function and tell me where it's trying to put
> the breakpoint, in particular what happens before and during
> insert_step_resume_breakpoint_at_sal.

I believe there's no breakpoint set because where the next software
single step breakpoint would be placed, there is already a breakpoint
there.  
Look at this slightly different run:

Num Type           Disp Enb Address    What
2   breakpoint     keep y   0xffffffff800019b0 in main at tmp.c:14
3   breakpoint     keep y   0xffffffff8000199c in main at tmp.c:11 <--
one instruction later than previous run

Sending packet: $m800019b0,4#91...Ack
Packet received: 03e00008
Sending packet: $M800019b0,4:0005000d#64...Ack
Packet received: OK
Sending packet: $m8000199c,4#9b...Ack
Packet received: afbf0010
Sending packet: $M8000199c,4:0005000d#6e...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: ENN
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 800019a4
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 80001990
Sending packet: $p1d#05...Ack
Packet received: 8402ba60
Sending packet: $p1f#07...Ack
Packet received: 800019a8
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $m800019a0,4#90...Ack
Packet received: 0c000664
Sending packet: $m800019a4,4#94...Ack
Packet received: 00000000
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $M80001998,4:0005000d#43...Ack <--- was explicit
breakpoint in previous run, but not this run
Packet received: OK
Sending packet: $c#63...Ack
Packet received: S02
Sending packet: $p25#d7...Ack
Packet received: 800019b0

Re: single stepping mips remote programs built with gcc 4.0

[Daniel Jacobowitz]

On Mon, Nov 21, 2005 at 09:25:45PM -0800, Newman, Sarah R wrote:
> (gdb) set debug remote 1
> (gdb) step
> Sending packet: $m80001998,4#70...Ack
> Packet received: 27bdffe8
> Sending packet: $M80001998,4:0005000d#43...Ack
> Packet received: OK
> Sending packet: $m800019b0,4#91...Ack
> Packet received: 03e00008
> Sending packet: $M800019b0,4:0005000d#64...Ack
> Packet received: OK

Insert breakpoints before stepping...

> Sending packet: $s#73...Ack
> Packet received: S05
> Sending packet: $p25#d7...Ack
> Packet received: 800019a4

Step over the jump... into the delay slot, which is not what GDB
expects, but hopefully that's not the problem here.

> Sending packet: $s#73...Ack
> Packet received: S05
> Sending packet: $p25#d7...Ack
> Packet received: 80001990
> Sending packet: $p1d#05...Ack
> Packet received: 8402ba60
> Sending packet: $p1f#07...Ack
> Packet received: 800019a8
> Sending packet: $m8000199c,4#9b...Ack
> Packet received: afbf0010
> Sending packet: $m800019a0,4#90...Ack
> Packet received: 0c000664
> Sending packet: $m800019a4,4#94...Ack
> Packet received: 00000000
> Sending packet: $c#63...Ack
> Packet received: S02
> Sending packet: $p25#d7...Ack
> Packet received: 800019b0

We realize we've stepped into a function call.  But we're continuing
without setting any breakpoint at all, which is bogus.

> #0  remote_resume (ptid={pid = -1, lwp = 0, tid = 0}, step=0,
>     siggnal=TARGET_SIGNAL_0) at ../../GDB-ISS/gdb/remote.c:2603
> #1  0x004240bb in resume (step=0, sig=TARGET_SIGNAL_0)
>     at ../../GDB-ISS/gdb/infrun.c:624
> #2  0x004278b7 in keep_going (ecs=0x22d810) at
> ../../GDB-ISS/gdb/infrun.c:2825
> #3  0x00427606 in step_into_function (ecs=0x22d810)
>     at ../../GDB-ISS/gdb/infrun.c:2708
> #4  0x00426d3a in handle_inferior_event (ecs=0x22d810)
>     at ../../GDB-ISS/gdb/infrun.c:2433

I can see no way at all for step_into_function to call keep_going
without inserting a stop breakpoint.  Obviously that's gone wrong.
Please step through that function and tell me where it's trying to put
the breakpoint, in particular what happens before and during
insert_step_resume_breakpoint_at_sal.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

> On Thu, Nov 17, 2005 at 02:23:17PM -0800, Newman, Sarah R wrote:
> > I built it with the default options, that good enough? 
> Something like
> > "-g -O2" it seems.
> > 
> > I doubt that mips32_next_pc is getting compiled in because 
> I can set a
> > breakpoint at mips_next_pc but not mips32_next_pc.  
> > mips_software_single_step never gets called in this 
> sequence, should it
> > be? 
> 
> Could you show me a session transcript?  If mips_software_single_step
> isn't placing the breakpoint, what is?
> 
> mips32_next_pc was probably inlined; you can retry with -g -O0 if you
> want.

mips32_next_pc is not being called.  

It seems that when gdb is single stepping at the source code level it
tries to skip over the function prologues (I could be wrong.)  I am
compiling with options "-g" and "-O2" and gcc 4.0 apparently removes the
prologues for very simple functions. I've been poking around
handle_inferior_event, mips_skip_prologue, and skip_prologue_using_sal
mostly.  I still think the very different assembly produced by gcc 4.0
is causing problems.  I may try comparing the 3.1 runtime behavior with
4.0 but I will have to recompile some libraries in order to do that and
it's late. :P  

Additionally, in the below source code, if you try to to do an assembly
listing within gdb of either function A or B, it shows the function
following within the disassembly.  IE disassembling function B displays
the code for A, and disassembling A displays the code for main, but main
is correctly displayed.

Some source code:

void b(int c){
  printf("%d",c+2);
}

void a(void){
  b(2);
}

int main(){
  a();
  return 0;
}

gcc 3.1 disassembly: 
8000198c <b>:
8000198c:	24850002 	addiu	a1,a0,2
80001990:	3c048403 	lui	a0,0x8403
80001994:	27bdffe8 	addiu	sp,sp,-24
80001998:	afbf0010 	sw	ra,16(sp)
8000199c:	0c002b57 	jal	8000ad5c <printf>
800019a0:	24848000 	addiu	a0,a0,-32768
800019a4:	8fbf0010 	lw	ra,16(sp)
800019a8:	00000000 	nop
800019ac:	03e00008 	jr	ra
800019b0:	27bd0018 	addiu	sp,sp,24

800019b4 <a>:
800019b4:	27bdffe8 	addiu	sp,sp,-24
800019b8:	afbf0010 	sw	ra,16(sp)
800019bc:	0c000663 	jal	8000198c <b>
800019c0:	24040002 	li	a0,2
800019c4:	8fbf0010 	lw	ra,16(sp)
800019c8:	00000000 	nop
800019cc:	03e00008 	jr	ra
800019d0:	27bd0018 	addiu	sp,sp,24

800019d4 <main>:
800019d4:	27bdffe8 	addiu	sp,sp,-24
800019d8:	afbf0010 	sw	ra,16(sp)
800019dc:	0c00066d 	jal	800019b4 <a>
800019e0:	00000000 	nop
800019e4:	8fbf0010 	lw	ra,16(sp)
800019e8:	00001021 	move	v0,zero
800019ec:	03e00008 	jr	ra
800019f0:	27bd0018 	addiu	sp,sp,24

gcc 4.0 disassembly:
80001980 <b>:
80001980:	24850002 	addiu	a1,a0,2
80001984:	3c048402 	lui	a0,0x8402
80001988:	08002b4a 	j	8000ad28 <printf>
8000198c:	24840100 	addiu	a0,a0,256

80001990 <a>:
80001990:	08000660 	j	80001980 <b>
80001994:	24040002 	li	a0,2

80001998 <main>:
80001998:	27bdffe8 	addiu	sp,sp,-24
8000199c:	afbf0010 	sw	ra,16(sp)
800019a0:	0c000664 	jal	80001990 <a>
800019a4:	00000000 	nop
800019a8:	8fbf0010 	lw	ra,16(sp)
800019ac:	00001021 	move	v0,zero
800019b0:	03e00008 	jr	ra
800019b4:	27bd0018 	addiu	sp,sp,24

--
run with 4.0 version:

(gdb) info breakpoints
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0xffffffff80001998 in main at tmp.c:11
2   breakpoint     keep y   0xffffffff800019b0 in main at tmp.c:14

(gdb) p/x $pc
$1 = 0x80001998

(gdb) step
(gdb) p/x $pc
$2 = 0x800019a0

(gdb) set debug remote 1
(gdb) step
Sending packet: $m80001998,4#70...Ack
Packet received: 27bdffe8
Sending packet: $M80001998,4:0005000d#43...Ack
Packet received: OK
Sending packet: $m800019b0,4#91...Ack
Packet received: 03e00008
Sending packet: $M800019b0,4:0005000d#64...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 800019a4
Sending packet: $s#73...Ack
Packet received: S05
Sending packet: $p25#d7...Ack
Packet received: 80001990
Sending packet: $p1d#05...Ack
Packet received: 8402ba60
Sending packet: $p1f#07...Ack
Packet received: 800019a8
Sending packet: $m8000199c,4#9b...Ack
Packet received: afbf0010
Sending packet: $m800019a0,4#90...Ack
Packet received: 0c000664
Sending packet: $m800019a4,4#94...Ack
Packet received: 00000000
Sending packet: $c#63...Ack
Packet received: S02
Sending packet: $p25#d7...Ack
Packet received: 800019b0

--
Backtrace taken right before the above continue:

#0  remote_resume (ptid={pid = -1, lwp = 0, tid = 0}, step=0,
    siggnal=TARGET_SIGNAL_0) at ../../GDB-ISS/gdb/remote.c:2603
#1  0x004240bb in resume (step=0, sig=TARGET_SIGNAL_0)
    at ../../GDB-ISS/gdb/infrun.c:624
#2  0x004278b7 in keep_going (ecs=0x22d810) at
../../GDB-ISS/gdb/infrun.c:2825
#3  0x00427606 in step_into_function (ecs=0x22d810)
    at ../../GDB-ISS/gdb/infrun.c:2708
#4  0x00426d3a in handle_inferior_event (ecs=0x22d810)
    at ../../GDB-ISS/gdb/infrun.c:2433
#5  0x0042467f in wait_for_inferior () at
../../GDB-ISS/gdb/infrun.c:1000
#6  0x004244c7 in proceed (addr=18446744073709551615,
    siggnal=TARGET_SIGNAL_DEFAULT, step=1) at
../../GDB-ISS/gdb/infrun.c:825
#7  0x00417cc4 in step_1 (skip_subroutines=0, single_inst=0,
count_string=0x0)
    at ../../GDB-ISS/gdb/infcmd.c:717
#8  0x004179ff in step_command (count_string=0x0, from_tty=1)
    at ../../GDB-ISS/gdb/infcmd.c:606

Re: single stepping mips remote programs built with gcc 4.0

[Daniel Jacobowitz]

On Thu, Nov 17, 2005 at 12:13:48PM -0800, Newman, Sarah R wrote:
> Hi, I have a version of gdb from CVS on 8/29/2005.  I have configured with the target as mips-elf and the host as cygwin and I am using it to connect to a remote mips system.  All of my programs I am trying to run remotely have been built with GCC 4+.  I am single stepping through code where part of it consists of something like the following in the disassembly listing:
> 
> 00003dac <initialize()>:
> 00003dac:	24040001 	li	a0,1
> 00003db0:	08000deb 	j	000037ac <setArraySize(int, int)>
> 00003db4:	24050001 	li	a1,1
> 
> 00003db8 <getCurrentBuffer2(int&)>:
> 00003db8:	3c02bd00 	lui	v0,0xbd00
> 
> When stopped at the beginning of the function, I can tell by looking
> at the remote protocol debug output that a breakpoint is being set in
> memory at the location of getCurrentBuffer2, not setArraySize.  We
> suspect that this may have to do with GCC 4+ doing straight jumps to
> other functions and not jump and link followed by jump register to
> leave the function.  Has anyone else encountered this or found a
> solution?

Could you please build a debuggable GDB binary, and trace through
mips32_next_pc?  It looks like it should handle the 'j' instruction
just fine:

        case 2:         /* J */
        case 3:         /* JAL */
          {
            unsigned long reg;
            reg = jtype_target (inst) << 2;
            /* Upper four bits get never changed... */
            pc = reg + ((pc + 4) & 0xf0000000);
          }
          break;

J and JAL share a format, so this should be correct.  It's as if the
value GDB is extracting for the instruction is incorrect.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

single stepping mips remote programs built with gcc 4.0

[Newman, Sarah R]

Hi, I have a version of gdb from CVS on 8/29/2005.  I have configured with the target as mips-elf and the host as cygwin and I am using it to connect to a remote mips system.  All of my programs I am trying to run remotely have been built with GCC 4+.  I am single stepping through code where part of it consists of something like the following in the disassembly listing:

00003dac <initialize()>:
00003dac:	24040001 	li	a0,1
00003db0:	08000deb 	j	000037ac <setArraySize(int, int)>
00003db4:	24050001 	li	a1,1

00003db8 <getCurrentBuffer2(int&)>:
00003db8:	3c02bd00 	lui	v0,0xbd00

When stopped at the beginning of the function, I can tell by looking at the remote protocol debug output that a breakpoint is being set in memory at the location of getCurrentBuffer2, not setArraySize.  We suspect that this may have to do with GCC 4+ doing straight jumps to other functions and not jump and link followed by jump register to leave the function.  Has anyone else encountered this or found a solution? 

Thank you,

Sarah Newman