From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-37404-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 7537 invoked by alias); 8 Dec 2004 16:32:16 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 7505 invoked from network); 8 Dec 2004 16:32:12 -0000
Received: from unknown (HELO takamaka.act-europe.fr) (212.157.227.139)
  by sourceware.org with SMTP; 8 Dec 2004 16:32:12 -0000
Received: by takamaka.act-europe.fr (Postfix, from userid 507)
	id B8DC347DAB; Wed,  8 Dec 2004 17:32:11 +0100 (CET)
Date: Wed, 08 Dec 2004 16:34:00 -0000
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFC] pb unwinding from pthread_cond_wait on ppc-linux (RFA?)
Message-ID: <20041208163211.GY2524@adacore.com>
References: <20041208155633.GX2524@adacore.com> <20041208161420.GA29978@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041208161420.GA29978@nevyn.them.org>
User-Agent: Mutt/1.4i
X-SW-Source: 2004-12/txt/msg00239.txt.bz2

> > I think that the reason that gdb-6.0 worked is a bit related to luck.
> > Here are the first few instructions of pthread_cond_timedwait():
> > 
> >     0x0ffe45b4 <pthread_cond_timedwait+0>:     stwu    r1,-128(r1)
> >     0x0ffe45b8 <pthread_cond_timedwait+4>:     mflr    r8
> >     0x0ffe45bc <pthread_cond_timedwait+8>:     lis     r7,15258
> >     0x0ffe45c0 <pthread_cond_timedwait+12>:    bl      0xffed01c
> >     0x0ffe45c4 <pthread_cond_timedwait+16>:    stw     r8,132(r1)
> 
> What's the bl actually calling?

(strange that the information appears to have gotten lost somewhere
during the copy/paste). According to GDB:

        bl      0xffed01c <stack_used+8>

But then, when I try to look deeper:

        (gdb) disass &stack_used
        Dump of assembler code for function stack_used:
        0x0ffed014 <stack_used+0>:      addic   r2,r2,-5280
        0x0ffed018 <stack_used+4>:      addic   r2,r2,-5280
        End of assembler dump.

ie, stack_used+8 does not exist... However:

        (gdb) x /10i 0xffed01c
        0xffed01c <stack_used+8>:       blrl
        0xffed020 <stack_used+12>:      .long 0x10f10
        0xffed024 <stack_used+16>:      .long 0x0
        0xffed028 <stack_used+20>:      .long 0x0
        0xffed02c <stack_used+24>:      twi     31,r30,-12756
        0xffed030 <stack_used+28>:      twi     31,r30,1928
        0xffed034 <stack_used+32>:      twi     31,r30,-24472
        0xffed038 <stack_used+36>:      twi     31,r30,-12280
        0xffed03c <stack_used+40>:      twi     31,r30,-11904
        0xffed040 <stack_used+44>:      twi     31,r30,-12276

Gah? Do I understand correctly that the code jumps to 0xffed01c
only to return back?

-- 
Joel