From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13407 invoked by alias); 9 Dec 2004 16:00:25 -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 13375 invoked from network); 9 Dec 2004 16:00:17 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (212.157.227.139) by sourceware.org with SMTP; 9 Dec 2004 16:00:17 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 0E17647DAD; Thu, 9 Dec 2004 17:00:17 +0100 (CET) Date: Thu, 09 Dec 2004 17:23: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: <20041209160017.GE1382@adacore.com> References: <20041208155633.GX2524@adacore.com> <20041208161420.GA29978@nevyn.them.org> <20041208163211.GY2524@adacore.com> <20041208163442.GA30584@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20041208163442.GA30584@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00250.txt.bz2 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 857 > 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 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ppc.diff" Content-length: 2013 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); --C7zPtVaVf+AK4Oqc--