From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13192 invoked by alias); 11 Oct 2006 16:03:40 -0000 Received: (qmail 13179 invoked by uid 22791); 11 Oct 2006 16:03:39 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Oct 2006 16:03:33 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 7E4F948CDF4 for ; Wed, 11 Oct 2006 12:03:31 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16958-01-6 for ; Wed, 11 Oct 2006 12:03:31 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 3214348CDDA for ; Wed, 11 Oct 2006 12:03:31 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 7093147F00; Wed, 11 Oct 2006 09:03:29 -0700 (PDT) Date: Wed, 11 Oct 2006 16:03:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC] pb unwinding from pthread_cond_wait on ppc-linux (RFA?) Message-ID: <20061011160329.GD1059@adacore.com> References: <20041208155633.GX2524@adacore.com> <20041208161420.GA29978@nevyn.them.org> <20041208163211.GY2524@adacore.com> <20041208163442.GA30584@nevyn.them.org> <20041209160017.GE1382@adacore.com> <20050209170211.GD18540@adacore.com> <20050617040635.GJ17013@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050617040635.GJ17013@nevyn.them.org> User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00119.txt.bz2 Hi Daniel, > > On Thu, Dec 09, 2004 at 05:00:17PM +0100, Joel Brobecker wrote: > > > > Precisely! That's what I thought it would be. It's trying to load lr > > > > with the address of @+16, so that the function can access PIC data > > > > using PC-relative displacement. > > > > > > Daniel, you never stop to impress me. > > > > > > > (Does this obsolete the "branch in first three insns" check? I'm not > > > > sure if there are other possible reasons for that.) > > > > > > Here is a new patch that implements your suggestion. Indeed, I could > > > then remove the "branch in first three insns" check... > > FYI, rethinking this, this is not such a good idea (removing the check, > I mean). While the check itself is pretty bogus, the comment above > says: > { /* bl foo, > to save fprs??? */ > > I know at least Darwin does this. > > So maybe the new check should be additional instead of a replacement. I am really sorry for dropping the ball on this one. I have reorganized my working schedule in an attempt to allow me to get back to some tasks that I left, so hopefully it'll work out. If Darwin does this, then you are probably right that the test should not be a replacement but an addition. Unfortunately, I no longer have access to a ppc-linux machine. I did the work back then as an evaluation of this port, but we ended up not adding this platform to our list of supported ones. Would you be able to do the testing? I can test on ppc-aix, though, but I'm thinking that this will likely not have much impact. -- Joel