Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[John Van Horne]

I just posted a note on PR 1716 about my experience with this problem. Basically,
"next" on a dynamically linked library function fails for me using gdb 6.2.1, 6.3
and 6.3.50.20050420. I saw the previous posts in this thread that made it sound as
though this was fixed in the 20050104 snapshot. However I couldn't find that snapshot,
and the latest failed for me.

I've got gdb configured for mips-linux-gnu, and I'm using gcc-3.3.4 and binutils-2.15.
As a test I'm using testsuite/gdb.base/call-strs.exp. Version 6.3.50.20050420 fails
on the "next" at line 73 (strcpy) with this message:

warning: GDB can't find the start of the function at 0x400cf0.

    GDB is unable to find the start of the function at 0x400cf0
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x400cf0 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
warning: GDB can't find the start of the function at 0x400cf0.
?? ()
 
The failure occurs both with native and remote debugging.
There's no failure when I "step" into "strcpy" and then finish it.

I'd be happy to provide any more information and would like to know if anyone's
working on this.

Thanks,
-John Van Horne
(not on mailing list, please cc jvh@tivo.com)

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Atsushi Nemoto]

>>>>> On Fri, 22 Apr 2005 15:39:06 -0700, "John Van Horne" <jvh@tivo.com> said:
jvh> I just posted a note on PR 1716 about my experience with this
jvh> problem. Basically, "next" on a dynamically linked library
jvh> function fails for me using gdb 6.2.1, 6.3 and 6.3.50.20050420. I
jvh> saw the previous posts in this thread that made it sound as
jvh> though this was fixed in the 20050104 snapshot. However I
jvh> couldn't find that snapshot, and the latest failed for me.

I tried 6.3.50.20050329 and 6.3.50.20050424 and got same errors.
It seems broken again before 20050329.

FYI, my ugly hack for gdb 6.3 seems work for current snapshot too.
(http://sources.redhat.com/ml/gdb/2004-12/msg00118.html)

---
Atsushi Nemoto

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Daniel Jacobowitz]

On Mon, Apr 25, 2005 at 03:21:57PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 22 Apr 2005 15:39:06 -0700, "John Van Horne" <jvh@tivo.com> said:
> jvh> I just posted a note on PR 1716 about my experience with this
> jvh> problem. Basically, "next" on a dynamically linked library
> jvh> function fails for me using gdb 6.2.1, 6.3 and 6.3.50.20050420. I
> jvh> saw the previous posts in this thread that made it sound as
> jvh> though this was fixed in the 20050104 snapshot. However I
> jvh> couldn't find that snapshot, and the latest failed for me.
> 
> I tried 6.3.50.20050329 and 6.3.50.20050424 and got same errors.
> It seems broken again before 20050329.
> 
> FYI, my ugly hack for gdb 6.3 seems work for current snapshot too.
> (http://sources.redhat.com/ml/gdb/2004-12/msg00118.html)

Drat.  I will look into this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Daniel Jacobowitz]

On Mon, Apr 25, 2005 at 09:01:25AM -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 25, 2005 at 03:21:57PM +0900, Atsushi Nemoto wrote:
> > >>>>> On Fri, 22 Apr 2005 15:39:06 -0700, "John Van Horne" <jvh@tivo.com> said:
> > jvh> I just posted a note on PR 1716 about my experience with this
> > jvh> problem. Basically, "next" on a dynamically linked library
> > jvh> function fails for me using gdb 6.2.1, 6.3 and 6.3.50.20050420. I
> > jvh> saw the previous posts in this thread that made it sound as
> > jvh> though this was fixed in the 20050104 snapshot. However I
> > jvh> couldn't find that snapshot, and the latest failed for me.
> > 
> > I tried 6.3.50.20050329 and 6.3.50.20050424 and got same errors.
> > It seems broken again before 20050329.
> > 
> > FYI, my ugly hack for gdb 6.3 seems work for current snapshot too.
> > (http://sources.redhat.com/ml/gdb/2004-12/msg00118.html)
> 
> Drat.  I will look into this.

So far, I can not reproduce the problem:

(gdb) b 73
Breakpoint 1 at 0x400c20: file /big/fsf/projects/mips-linux/src/gdb/testsuite/gdb.base/call-strs.c, line 73.
(gdb) r
Starting program: /nevyn/big/fsf/projects/mips-linux/gdb/testsuite/gdb.base/call-strs 

Breakpoint 1, main () at /big/fsf/projects/mips-linux/src/gdb/testsuite/gdb.base/call-strs.c:73
73        strcpy(buf, "test string");
(gdb) n
74        str_func("abcd", "efgh", "ijkl", "mnop", "qrst", "uvwx", "yz12");
(gdb) 

This is 6.3.50.20050403-cvs.  I also updated and tested with
6.3.50.20050427-cvs.  Also works fine.

It must be something different between your userland and mine.  I'm
using a somewhat patched binutils 2.14 and GCC 3.3.1.  Glibc is a CVS
snapshot around 2.3.2.

With "set debug infrun 1" I see this behavior:

infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400c38
infrun: stepping inside range [0x400c20-0x400c48]
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x2ac623a0
infrun: stepped into subroutine
infrun: resume (step=0, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400c40
infrun: BPSTATE_WHAT_STEP_RESUME
infrun: stepping inside range [0x400c20-0x400c48]
infrun: resume (step=1, signal=0)

Hmm, no step into the lazy resolution stub; it's already been resolved
to strcpy.  The system I'm doing all my testing on apparently does not
do lazy binding :-(  Looks like a binutils problem - I believe I
remember fixing this bug some time after binutils 2.14 was released.

I'll keep trying to reproduce this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Daniel Jacobowitz]

On Wed, Apr 27, 2005 at 09:43:06AM -0400, Daniel Jacobowitz wrote:
> Hmm, no step into the lazy resolution stub; it's already been resolved
> to strcpy.  The system I'm doing all my testing on apparently does not
> do lazy binding :-(  Looks like a binutils problem - I believe I
> remember fixing this bug some time after binutils 2.14 was released.
> 
> I'll keep trying to reproduce this.

Got it.  Could either of you please test this patch?  Without it, I get
failures in call-strs.exp; with it, everything passes.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-04-27  Daniel Jacobowitz  <dan@codesourcery.com>

	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
	section like .plt.

Index: mips-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/mips-tdep.c,v
retrieving revision 1.379
diff -u -p -r1.379 mips-tdep.c
--- mips-tdep.c	17 Mar 2005 18:07:46 -0000	1.379
+++ mips-tdep.c	27 Apr 2005 14:12:21 -0000
@@ -2091,11 +2091,21 @@ static const struct frame_unwind mips_st
 static const struct frame_unwind *
 mips_stub_frame_sniffer (struct frame_info *next_frame)
 {
+  struct obj_section *s;
   CORE_ADDR pc = frame_pc_unwind (next_frame);
+
   if (in_plt_section (pc, NULL))
     return &mips_stub_frame_unwind;
-  else
-    return NULL;
+
+  /* Binutils for MIPS puts lazy resolution stubs into .MIPS.stubs.  */
+  s = find_pc_section (pc);
+
+  if (s != NULL
+      && strcmp (bfd_get_section_name (s->objfile->obfd, s->the_bfd_section),
+		 ".MIPS.stubs") == 0)
+    return &mips_stub_frame_unwind;
+
+  return NULL;
 }
 
 static CORE_ADDR

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Atsushi Nemoto]

>>>>> On Wed, 27 Apr 2005 10:17:14 -0400, Daniel Jacobowitz <drow@false.org> said:
drow> Got it.  Could either of you please test this patch?  Without
drow> it, I get failures in call-strs.exp; with it, everything passes.

It works for me too (with 6.3.50.20050424).  Thanks!

---
Atsushi Nemoto

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Atsushi Nemoto]

>>>>> On Wed, 27 Apr 2005 10:17:14 -0400, Daniel Jacobowitz <drow@false.org> said:
drow> 2005-04-27  Daniel Jacobowitz  <dan@codesourcery.com>

drow> 	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
drow> 	section like .plt.

This fix still not be checked in.  Is there any problem with this
patch?

---
Atsushi Nemoto

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Daniel Jacobowitz]

On Mon, May 09, 2005 at 12:16:35PM +0900, Atsushi Nemoto wrote:
> >>>>> On Wed, 27 Apr 2005 10:17:14 -0400, Daniel Jacobowitz <drow@false.org> said:
> drow> 2005-04-27  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> drow> 	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
> drow> 	section like .plt.
> 
> This fix still not be checked in.  Is there any problem with this
> patch?

None; I forgot about it!  Sorry.

I have checked in the attached.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-05-08  Daniel Jacobowitz  <dan@codesourcery.com>

	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
	section like .plt.

Index: mips-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/mips-tdep.c,v
retrieving revision 1.379
diff -u -p -r1.379 mips-tdep.c
--- mips-tdep.c	17 Mar 2005 18:07:46 -0000	1.379
+++ mips-tdep.c	27 Apr 2005 14:12:21 -0000
@@ -2091,11 +2091,21 @@ static const struct frame_unwind mips_st
 static const struct frame_unwind *
 mips_stub_frame_sniffer (struct frame_info *next_frame)
 {
+  struct obj_section *s;
   CORE_ADDR pc = frame_pc_unwind (next_frame);
+
   if (in_plt_section (pc, NULL))
     return &mips_stub_frame_unwind;
-  else
-    return NULL;
+
+  /* Binutils for MIPS puts lazy resolution stubs into .MIPS.stubs.  */
+  s = find_pc_section (pc);
+
+  if (s != NULL
+      && strcmp (bfd_get_section_name (s->objfile->obfd, s->the_bfd_section),
+		 ".MIPS.stubs") == 0)
+    return &mips_stub_frame_unwind;
+
+  return NULL;
 }
 
 static CORE_ADDR

RE: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[John Van Horne]

Daniel,

I applied your patch to my copy of 6.3.50.20050420, ran testsuite/gdb.base/call-strs.exp,
and it passed. Thanks. This is great.

-John

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: Wednesday, April 27, 2005 7:17 AM
> To: Atsushi Nemoto; John Van Horne; gdb@sources.redhat.com
> Subject: Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux
> 
> 
> On Wed, Apr 27, 2005 at 09:43:06AM -0400, Daniel Jacobowitz wrote:
> > Hmm, no step into the lazy resolution stub; it's already 
> been resolved
> > to strcpy.  The system I'm doing all my testing on 
> apparently does not
> > do lazy binding :-(  Looks like a binutils problem - I believe I
> > remember fixing this bug some time after binutils 2.14 was released.
> > 
> > I'll keep trying to reproduce this.
> 
> Got it.  Could either of you please test this patch?  Without 
> it, I get
> failures in call-strs.exp; with it, everything passes.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 
> 2005-04-27  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
> 	section like .plt.
> 
> Index: mips-tdep.c
> ===================================================================
> RCS file: /big/fsf/rsync/src-cvs/src/gdb/mips-tdep.c,v
> retrieving revision 1.379
> diff -u -p -r1.379 mips-tdep.c
> --- mips-tdep.c	17 Mar 2005 18:07:46 -0000	1.379
> +++ mips-tdep.c	27 Apr 2005 14:12:21 -0000
> @@ -2091,11 +2091,21 @@ static const struct frame_unwind mips_st
>  static const struct frame_unwind *
>  mips_stub_frame_sniffer (struct frame_info *next_frame)
>  {
> +  struct obj_section *s;
>    CORE_ADDR pc = frame_pc_unwind (next_frame);
> +
>    if (in_plt_section (pc, NULL))
>      return &mips_stub_frame_unwind;
> -  else
> -    return NULL;
> +
> +  /* Binutils for MIPS puts lazy resolution stubs into 
> .MIPS.stubs.  */
> +  s = find_pc_section (pc);
> +
> +  if (s != NULL
> +      && strcmp (bfd_get_section_name (s->objfile->obfd, 
> s->the_bfd_section),
> +		 ".MIPS.stubs") == 0)
> +    return &mips_stub_frame_unwind;
> +
> +  return NULL;
>  }
>  
>  static CORE_ADDR
> 

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Daniel Jacobowitz]

On Thu, Jan 06, 2005 at 07:37:10PM +0900, Atsushi Nemoto wrote:
> >>>>> On Tue, 04 Jan 2005 15:29:59 -0500, Andrew Cagney <cagney@gnu.org> said:
> >> I found PR#1716 (for gdb 6.1.1).  Is this solved on gdb 6.3?
> 
> cagney> Can you test/debug a mainline GDB?  The MIPS code has been
> cagney> completely overhauled.
> 
> I tried 20050104 weekly snapshot and it seems OK.  Thank you.
> 
> BTW, Daniel Jacobowitz told me that he know something about this
> problem.  Daniel, the problem you mentioned was solved already in
> mainline?

I didn't know that, but it's great news!  Probably Joel fixed it.

-- 
Daniel Jacobowitz

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Atsushi Nemoto]

>>>>> On Tue, 04 Jan 2005 15:29:59 -0500, Andrew Cagney <cagney@gnu.org> said:
>> I found PR#1716 (for gdb 6.1.1).  Is this solved on gdb 6.3?

cagney> Can you test/debug a mainline GDB?  The MIPS code has been
cagney> completely overhauled.

I tried 20050104 weekly snapshot and it seems OK.  Thank you.

BTW, Daniel Jacobowitz told me that he know something about this
problem.  Daniel, the problem you mentioned was solved already in
mainline?

---
Atsushi Nemoto

Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Andrew Cagney]

Atsushi Nemoto wrote:
> Hi.  I noticed gdb 6.3 'next' command does not work (even for the
> "hello world" program) on mips-linux/mipsel-linux.  It works well for
> statically linked programs.
> 
> I found PR#1716 (for gdb 6.1.1).  Is this solved on gdb 6.3?

Can you test/debug a mainline GDB?  The MIPS code has been completely 
overhauled.

Andrew

> Also I found discussions in this ML (Subject: "Unable to step over (n
> and ni) on mipsel-linux...")  but can not see final solution.
> 
> Here is my inspection:
> 
> When 'next' failed, following call (infrun.c:1772) stores 0 in
> ecs->stop_func_start.
> 
>   find_pc_partial_function (stop_pc, &ecs->stop_func_name,
> 			    &ecs->stop_func_start, &ecs->stop_func_end);
> 
> More exactly, following call (blockframe.c:211) returned NULL.
> 
>   msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, section);
> 
> 'mapped_pc' was an address of a STUB section to the libc function
> (printf) and 'section' was ".MIPS.stubs".
> 
> When I tried gdb 5.3, the 'section' variable was NULL in that point.
> 
> So I suppose something wrong with ".MIPS.stubs" section handling.
> 
> With this quick and dirty hack, 'next' command works well.
> 
> --- gdb-6.3.org/gdb/blockframe.c	2004-09-01 23:13:31.000000000 +0900
> +++ gdb-6.3/gdb/blockframe.c	2004-12-24 17:50:27.747543472 +0900
> @@ -199,6 +199,10 @@
>  	section = NULL;
>        else
>  	section = obj_section->the_bfd_section;
> +#if 1	/* dirty hack... */
> +      if (section && strcmp(section->name, ".MIPS.stubs") == 0)
> +	section = NULL;
> +#endif
>      }
>  
>    mapped_pc = overlay_mapped_address (pc, section);
> 
> 
> I do not think this hack is correct at all, but hope it helps fixing
> the real problem.
> 
> Thank you.
> 
> 
> P.S.  I'm not on this ML.  Please CC to me.
> ---
> Atsushi Nemoto
> 

gdb 6.x 'next' does not work on mips-linux/mipsel-linux

[Atsushi Nemoto]

Hi.  I noticed gdb 6.3 'next' command does not work (even for the
"hello world" program) on mips-linux/mipsel-linux.  It works well for
statically linked programs.

I found PR#1716 (for gdb 6.1.1).  Is this solved on gdb 6.3?

Also I found discussions in this ML (Subject: "Unable to step over (n
and ni) on mipsel-linux...")  but can not see final solution.

Here is my inspection:

When 'next' failed, following call (infrun.c:1772) stores 0 in
ecs->stop_func_start.

  find_pc_partial_function (stop_pc, &ecs->stop_func_name,
			    &ecs->stop_func_start, &ecs->stop_func_end);

More exactly, following call (blockframe.c:211) returned NULL.

  msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, section);

'mapped_pc' was an address of a STUB section to the libc function
(printf) and 'section' was ".MIPS.stubs".

When I tried gdb 5.3, the 'section' variable was NULL in that point.

So I suppose something wrong with ".MIPS.stubs" section handling.

With this quick and dirty hack, 'next' command works well.

--- gdb-6.3.org/gdb/blockframe.c	2004-09-01 23:13:31.000000000 +0900
+++ gdb-6.3/gdb/blockframe.c	2004-12-24 17:50:27.747543472 +0900
@@ -199,6 +199,10 @@
 	section = NULL;
       else
 	section = obj_section->the_bfd_section;
+#if 1	/* dirty hack... */
+      if (section && strcmp(section->name, ".MIPS.stubs") == 0)
+	section = NULL;
+#endif
     }
 
   mapped_pc = overlay_mapped_address (pc, section);


I do not think this hack is correct at all, but hope it helps fixing
the real problem.

Thank you.


P.S.  I'm not on this ML.  Please CC to me.
---
Atsushi Nemoto