Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>,
	"'gdb-patches@sourceware.org'"	<gdb-patches@sourceware.org>
Subject: Re: [PATCH] Relax ARM prologue unwinder assumption
Date: Mon, 09 Feb 2015 14:51:00 -0000	[thread overview]
Message-ID: <54D8C95D.7000600@codesourcery.com> (raw)
In-Reply-To: <54D4DCE4.4060209@redhat.com>

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

On 02/06/2015 01:25 PM, Pedro Alves wrote:
> On 02/05/2015 07:06 PM, Luis Machado wrote:
>> Just recently i ran into a problem with a bare metal ARM target where
>> GDB would not allow some registers to be changed after the PC was
>> manually set to some other value.
>>
>> In reality the target had just started and one of its cores, out of
>> four, was running the program, but the other ones were in some random state.
>>
>> The PC of one of the other 3 cores was then adjusted to point to a known
>> function address.
>>
>> GDB's reaction to this change is to invalidate the regcache and frame
>> and build a brand new chain and cache, while trying to retain the
>> previously selected frame - #0 in this case.
>>
>> What i noticed is that GDB was selecting frame #1 instead of #0 due to
>> unfortunate coincidences with both frames' SP's being 0. And we can't
>> modify some registers on non-innermost frames for obvious reasons.
>>
>> Here's a brief log of what happens:
>>
>>
>> [Switching to thread 2 (Thread 2)]
>> #0  0x0093ff10 in ?? ()
>> (gdb) set $pc=functioncore2
>> (gdb) bt
>> #0  functioncore2 () at test.c:32
>> #1  0x0000fc44 in ?? ()
>
> So in this case, frame #0's unwinder must now be the dwarf
> unwinder, right?
>

Correct.

>> The attached patch removes this restriction and does not cause any
>> regressions for ARM bare metal, but i'd like feedback.
>
> Nowadays we have the frame_unwind_stop_reason hook to make it possible
> to have different outermost frame ids, but still have the frame claim
> that its the outermost, instead of forcing all outermost frame ids
> use the outer_frame_id id.  See i386_frame_unwind_stop_reason.
>
> Sounds like ARM could add an arm_frame_unwind_stop_reason that
> returns UNWIND_OUTERMOST when prev_sp is 0.
>
> And it looks like this bit here:
>
>    /* This is meant to halt the backtrace at "_start".  */
>    pc = get_frame_pc (this_frame);
>    if (pc <= gdbarch_tdep (get_frame_arch (this_frame))->lowest_pc)
>      return;
>
> can well cause a fail in the same way.
>

Thanks. That mechanism does sound a bit more flexible and it indeed 
solves the problem i'm seeing.

How does the updated patch look? I have arm_prologue_unwind_stop_reason 
implemented now.

> (It may also make sense to think through the cases where we are
> trying to restore the selected frame, and change that code.  It may be
> that it never makes sense to go from frame #0 to any other frame
> number, for instance.)

Trying to come up with the best match for a certain frame that 
potentially does not exist anymore can be troublesome, but it's been 
working well so far. I'd go for always picking up frame 0 as well. It is 
easier, cleaner and less prone to failures.

Luis

[-- Attachment #2: arm_unwind.diff --]
[-- Type: text/x-patch, Size: 2318 bytes --]

2015-02-09  Luis Machado  <lgustavo@codesourcery.com>

	* arm-tdep.c (arm_prologue_unwind_stop_reason): New function.
	(arm_prologue_this_id): Move PC and SP limit checks to
	arm_prologue_unwind_stop_reason.
	(arm_prologue_unwind) <stop_reason> : Set to
	arm_prologue_unwind_stop_reason.

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 8e9552a..f3a6325 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -2021,6 +2021,31 @@ arm_make_prologue_cache (struct frame_info *this_frame)
   return cache;
 }
 
+/* Implementation of the stop_reason hook for arm_prologue frames.  */
+
+static enum unwind_stop_reason
+arm_prologue_unwind_stop_reason (struct frame_info *this_frame,
+				 void **this_cache)
+{
+  struct arm_prologue_cache *cache;
+  CORE_ADDR pc;
+
+  if (*this_cache == NULL)
+    *this_cache = arm_make_prologue_cache (this_frame);
+  cache = *this_cache;
+
+  /* This is meant to halt the backtrace at "_start".  */
+  pc = get_frame_pc (this_frame);
+  if (pc <= gdbarch_tdep (get_frame_arch (this_frame))->lowest_pc)
+    return UNWIND_OUTERMOST;
+
+  /* If we've hit a wall, stop.  */
+  if (cache->prev_sp == 0)
+    return UNWIND_OUTERMOST;
+
+  return UNWIND_NO_REASON;
+}
+
 /* Our frame ID for a normal frame is the current function's starting PC
    and the caller's SP when we were called.  */
 
@@ -2037,18 +2062,10 @@ arm_prologue_this_id (struct frame_info *this_frame,
     *this_cache = arm_make_prologue_cache (this_frame);
   cache = *this_cache;
 
-  /* This is meant to halt the backtrace at "_start".  */
-  pc = get_frame_pc (this_frame);
-  if (pc <= gdbarch_tdep (get_frame_arch (this_frame))->lowest_pc)
-    return;
-
-  /* If we've hit a wall, stop.  */
-  if (cache->prev_sp == 0)
-    return;
-
   /* Use function start address as part of the frame ID.  If we cannot
      identify the start address (due to missing symbol information),
      fall back to just using the current PC.  */
+  pc = get_frame_pc (this_frame);
   func = get_frame_func (this_frame);
   if (!func)
     func = pc;
@@ -2117,7 +2134,7 @@ arm_prologue_prev_register (struct frame_info *this_frame,
 
 struct frame_unwind arm_prologue_unwind = {
   NORMAL_FRAME,
-  default_frame_unwind_stop_reason,
+  arm_prologue_unwind_stop_reason,
   arm_prologue_this_id,
   arm_prologue_prev_register,
   NULL,

  reply	other threads:[~2015-02-09 14:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05 19:07 Luis Machado
2015-02-06 15:25 ` Pedro Alves
2015-02-09 14:51   ` Luis Machado [this message]
2015-02-10  9:38     ` Pedro Alves
2015-02-10 11:52       ` Luis Machado

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=54D8C95D.7000600@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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