Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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?)
Date: Wed, 09 Feb 2005 17:08:00 -0000	[thread overview]
Message-ID: <20050209170211.GD18540@adacore.com> (raw)
In-Reply-To: <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


  reply	other threads:[~2005-02-09 17:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-08 15:59 Joel Brobecker
2004-12-08 16:32 ` Daniel Jacobowitz
2004-12-08 16:34   ` Joel Brobecker
2004-12-08 16:51     ` Daniel Jacobowitz
2004-12-09 17:23       ` Joel Brobecker
2005-02-09 17:08         ` Joel Brobecker [this message]
2005-06-17  4:07           ` Daniel Jacobowitz
2006-10-11 16:03             ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050209170211.GD18540@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox