From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19242 invoked by alias); 27 Apr 2005 13:44:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18031 invoked from network); 27 Apr 2005 13:43:08 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 27 Apr 2005 13:43:08 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DQmok-0007eF-9s; Wed, 27 Apr 2005 09:43:06 -0400 Date: Wed, 27 Apr 2005 14:18:00 -0000 From: Daniel Jacobowitz To: Atsushi Nemoto , jvh@tivo.com, gdb@sources.redhat.com Subject: Re: gdb 6.x 'next' does not work on mips-linux/mipsel-linux Message-ID: <20050427134305.GA10305@nevyn.them.org> Mail-Followup-To: Atsushi Nemoto , jvh@tivo.com, gdb@sources.redhat.com References: <20050425.152157.34482010.nemoto@toshiba-tops.co.jp> <20050425130124.GA7316@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425130124.GA7316@nevyn.them.org> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00197.txt.bz2 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" 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