This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] pb unwinding from pthread_cond_wait on ppc-linux (RFA?)
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Wed, 9 Feb 2005 12:02:11 -0500
- Subject: Re: [RFC] pb unwinding from pthread_cond_wait on ppc-linux (RFA?)
- References: <20041208155633.GX2524@adacore.com> <20041208161420.GA29978@nevyn.them.org> <20041208163211.GY2524@adacore.com> <20041208163442.GA30584@nevyn.them.org> <20041209160017.GE1382@adacore.com>
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 <brobecker@gnat.com>
>
> * 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