Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org, brobecker@adacore.com
Subject: Re: [PATCH] Fix PPC non-CFI + CFI unwinding (incomplete in HEAD)
Date: Sun, 14 Jan 2007 21:34:00 -0000	[thread overview]
Message-ID: <20070114213414.GA5184@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20070113164028.GA29436@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Sat, 13 Jan 2007 17:40:28 +0100, Daniel Jacobowitz wrote:
...
> I was thinking of this:
>   http://sourceware.org/ml/gdb-patches/2004-12/msg00249.html
>   http://sourceware.org/ml/gdb-patches/2005-06/msg00242.html
> 
> I think someone needs to combine Joel's and Jan's patches.  Joel's is
> nicer in that it uses branch_dest and the right mask for blrl; Jan's
> is nicer in that it checks whether lr was saved or is now lost.

Attached for:
	http://sourceware.org/ml/gdb-patches/2004-12/msg00249.html
and it does not handle in any way
	http://sourceware.org/ml/gdb-patches/2005-06/msg00242.html
as it would be IMO more appropriate to base it on the called code content but
"I do not have that Darwin code".



Regards,
Jan

[-- Attachment #2: gdb-ppc-combo.patch --]
[-- Type: text/plain, Size: 2362 bytes --]

2007-01-14  Joel Brobecker  <brobecker@gnat.com>
	    Jan Kratochvil <jan.kratochvil@redhat.com>

	* rs6000-tdep.c (bl_to_blrl_insn_p): New function.
	(skip_prologue): Allow bl->blrl used by a PIC code.


--- gdb/rs6000-tdep.c	9 Jan 2007 17:58:57 -0000	1.260
+++ gdb/rs6000-tdep.c	14 Jan 2007 21:24:51 -0000
@@ -902,6 +902,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)
 {
@@ -1133,18 +1157,19 @@ 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))
+	    {
+	      /* If we did not yet retrieved LR into some GPR
+		 all our chances are lost.  On the other hand already
+		 stored LR is still kept intact in its GPR.  */
+	      if (lr_reg == -1)
+		{
+		  /* Invalidate lr_reg, but don't set it to -1.
+		     That would mean that it had never been set.  */
+		  lr_reg = -2;
+		}
+	      continue;
 	    }
 
 	  op = read_memory_integer (pc + 4, 4);

  reply	other threads:[~2007-01-14 21:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-13  9:31 Jan Kratochvil
2007-01-13 16:04 ` Daniel Jacobowitz
2007-01-13 16:32   ` Mark Kettenis
2007-01-13 16:40     ` Daniel Jacobowitz
2007-01-14 21:34       ` Jan Kratochvil [this message]
2007-01-20 19:57         ` Daniel Jacobowitz
2007-01-21 10:41           ` Mark Kettenis
2007-01-21 21:47           ` Jan Kratochvil
2007-02-08 14:24             ` Daniel Jacobowitz

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=20070114213414.GA5184@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    /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