From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-21296-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 9691 invoked by alias); 27 Apr 2005 16:00:04 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 8498 invoked from network); 27 Apr 2005 15:59:16 -0000
Received: from unknown (HELO corpexch01.Tivo.com) (204.176.49.25)
  by sourceware.org with SMTP; 27 Apr 2005 15:59:16 -0000
Received: from corpexch10.Tivo.com ([192.168.180.200]) by corpexch01.Tivo.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 27 Apr 2005 08:59:16 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: gdb 6.x 'next' does not work on mips-linux/mipsel-linux
Date: Wed, 27 Apr 2005 16:36:00 -0000
Message-ID: <FD1AF2638CCA3044B61D2D778A4F204501D994@corpexch10.Tivo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "John Van Horne" <jvh@tivo.com>
To: "Daniel Jacobowitz" <drow@false.org>,
	"Atsushi Nemoto" <anemo@mba.ocn.ne.jp>,
	<gdb@sources.redhat.com>
X-OriginalArrivalTime: 27 Apr 2005 15:59:16.0033 (UTC) FILETIME=[101F2B10:01C54B42]
X-SW-Source: 2005-04/txt/msg00199.txt.bz2

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
>=20
>=20
> On Wed, Apr 27, 2005 at 09:43:06AM -0400, Daniel Jacobowitz wrote:
> > Hmm, no step into the lazy resolution stub; it's already=20
> been resolved
> > to strcpy.  The system I'm doing all my testing on=20
> 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.
> >=20
> > I'll keep trying to reproduce this.
>=20
> Got it.  Could either of you please test this patch?  Without=20
> it, I get
> failures in call-strs.exp; with it, everything passes.
>=20
> --=20
> Daniel Jacobowitz
> CodeSourcery, LLC
>=20
> 2005-04-27  Daniel Jacobowitz  <dan@codesourcery.com>
>=20
> 	* mips-tdep.c (mips_stub_frame_sniffer): Handle .MIPS.stubs
> 	section like .plt.
>=20
> Index: mips-tdep.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 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 =3D 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=20
> .MIPS.stubs.  */
> +  s =3D find_pc_section (pc);
> +
> +  if (s !=3D NULL
> +      && strcmp (bfd_get_section_name (s->objfile->obfd,=20
> s->the_bfd_section),
> +		 ".MIPS.stubs") =3D=3D 0)
> +    return &mips_stub_frame_unwind;
> +
> +  return NULL;
>  }
>=20=20
>  static CORE_ADDR
>=20