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

[Daniel Jacobowitz <drow@false.org>]

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