From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22059 invoked by alias); 9 Feb 2005 17:02:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22006 invoked from network); 9 Feb 2005 17:02:12 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (205.232.38.116) by sourceware.org with SMTP; 9 Feb 2005 17:02:12 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id EB59A47DBA; Wed, 9 Feb 2005 12:02:11 -0500 (EST) Date: Wed, 09 Feb 2005 17:08: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: <20050209170211.GD18540@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209160017.GE1382@adacore.com> User-Agent: Mutt/1.4i X-SW-Source: 2005-02/txt/msg00061.txt.bz2 Ping? 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... > > 2004-12-09 Joel Brobecker > > * rs6000-tdep.c (bl_to_blrl_insn_p): New function. > (skip_prologue): Stop unconditionaly skipping "bl" instructions > that are within the first 3 instruction. Instead, Skip that "bl" > instruction iff the destination instruction is a "blrl". > > Tested on powerpc-linux. No regression. > > How does it look? > > -- > Joel > Index: rs6000-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v > retrieving revision 1.233 > diff -u -p -r1.233 rs6000-tdep.c > --- rs6000-tdep.c 25 Nov 2004 02:48:27 -0000 1.233 > +++ rs6000-tdep.c 9 Dec 2004 15:40:46 -0000 > @@ -823,6 +823,30 @@ store_param_on_stack_p (unsigned long op > return 0; > } > > +/* Assuming that INSN is a "bl" instruction located at PC, return > + nonzero if the destination of the branch is a "blrl" instruction. > + > + This sequence is sometimes found in certain function prologues. > + It allows the function to load the LR register with a value that > + they can use to access PIC data using PC-relative offsets. */ > + > +static int > +bl_to_blrl_insn_p (CORE_ADDR pc, int insn) > +{ > + const int opcode = 18; > + const CORE_ADDR dest = branch_dest (opcode, insn, pc, -1); > + int dest_insn; > + > + if (dest == -1) > + return 0; /* Should never happen, but just return zero to be safe. */ > + > + dest_insn = read_memory_integer (dest, 4); > + if ((dest_insn & 0xfc00ffff) == 0x4c000021) /* blrl */ > + return 1; > + > + return 0; > +} > + > static CORE_ADDR > skip_prologue (CORE_ADDR pc, CORE_ADDR lim_pc, struct rs6000_framedata *fdata) > { > @@ -1047,19 +1071,9 @@ skip_prologue (CORE_ADDR pc, CORE_ADDR l > to save fprs??? */ > > fdata->frameless = 0; > - /* Don't skip over the subroutine call if it is not within > - the first three instructions of the prologue and either > - we have no line table information or the line info tells > - us that the subroutine call is not part of the line > - associated with the prologue. */ > - if ((pc - orig_pc) > 8) > - { > - struct symtab_and_line prologue_sal = find_pc_line (orig_pc, 0); > - struct symtab_and_line this_sal = find_pc_line (pc, 0); > > - if ((prologue_sal.line == 0) || (prologue_sal.line != this_sal.line)) > - break; > - } > + if (bl_to_blrl_insn_p (pc, op)) > + continue; > > op = read_memory_integer (pc + 4, 4); > -- Joel