From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Yao Qi <yao@codesourcery.com>, GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix gdb.trace/mi-traceframe-changed.exp to check for target trace support
Date: Thu, 16 Jan 2014 18:20:00 -0000 [thread overview]
Message-ID: <52D822DC.8000205@redhat.com> (raw)
In-Reply-To: <m34n55c76w.fsf@redhat.com>
On 01/15/2014 08:37 PM, Sergio Durigan Junior wrote:
> Yes, confirming that it passes with the patch. Sorry for taking long to
> test, I had issues trying to get another s390x machine to test it.
>
> Thanks for the patch and the further investigation.
Thank you. Patch is now pushed, as below.
------
Fix gdb.trace/mi-traceframe-changed.exp on s390.
The test fails on s390 with:
-trace-find frame-number 0^M
&"PC not available\n"^M
^done,found="1",tracepoint="1",traceframe="0",frame={level="-1",addr="<unavailable>",func="??",args=[]}^M
(gdb) ^M
FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
tfile knows to infer the PC from the tracepoint's address if the PC
wasn't collected (tfile_fetch_registers) but, that only works on
targets whose PC register is a raw register, and on s390, the PC
register is a pseudo register.
But even if GDB doesn't know how to infer the value of PC, saying the
current frame is level -1 is a bug:
^done,found="1",tracepoint="1",traceframe="0",frame={level="-1",addr="<unavailable>",func="??",args=[]}^M
^^^^^^^^^
'-1' is the level of the sentinel frame, which should never be visible.
This is caused by the s390's heuristic unwinder accepting the frame
(the fallback heuristic unwinders _always_ accept the frame), but then
the unwind->this_id method throws that "PC not available\n" error.
IOW, the s390's heuristic unwinder was never adjusted to handle
unavailable register values gracefully, which can happen with e.g., a
trimmed core file too.
This is just the minimal necessary for
<unavailable> frames, which at least gets us:
(gdb) tfind
Found trace frame 0, tracepoint 1
#0 <unavailable> in ?? ()
That is, frame #0 instead of -1.
We could get better info out of "info frame" (this patch makes us show
"outermost"), but this change would still be necessary.
gdb/
2014-01-16 Pedro Alves <palves@redhat.com>
* s390-linux-tdep.c (s390_frame_unwind_cache): Swallow
NOT_AVAILABLE_ERROR errors while parsing the prologue or reading
the backchain.
---
gdb/ChangeLog | 6 ++++++
gdb/s390-linux-tdep.c | 15 +++++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index f614f1b..6eef81a 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2014-01-16 Pedro Alves <palves@redhat.com>
+
+ * s390-linux-tdep.c (s390_frame_unwind_cache): Swallow
+ NOT_AVAILABLE_ERROR errors while parsing the prologue or reading
+ the backchain.
+
2014-01-16 Doug Evans <dje@google.com>
* dwarf2read.c (open_and_init_dwp_file): Fix typo in comment.
diff --git a/gdb/s390-linux-tdep.c b/gdb/s390-linux-tdep.c
index b75c86a..8b71e78 100644
--- a/gdb/s390-linux-tdep.c
+++ b/gdb/s390-linux-tdep.c
@@ -2039,7 +2039,9 @@ static struct s390_unwind_cache *
s390_frame_unwind_cache (struct frame_info *this_frame,
void **this_prologue_cache)
{
+ volatile struct gdb_exception ex;
struct s390_unwind_cache *info;
+
if (*this_prologue_cache)
return *this_prologue_cache;
@@ -2050,10 +2052,15 @@ s390_frame_unwind_cache (struct frame_info *this_frame,
info->frame_base = -1;
info->local_base = -1;
- /* Try to use prologue analysis to fill the unwind cache.
- If this fails, fall back to reading the stack backchain. */
- if (!s390_prologue_frame_unwind_cache (this_frame, info))
- s390_backchain_frame_unwind_cache (this_frame, info);
+ TRY_CATCH (ex, RETURN_MASK_ERROR)
+ {
+ /* Try to use prologue analysis to fill the unwind cache.
+ If this fails, fall back to reading the stack backchain. */
+ if (!s390_prologue_frame_unwind_cache (this_frame, info))
+ s390_backchain_frame_unwind_cache (this_frame, info);
+ }
+ if (ex.reason < 0 && ex.error != NOT_AVAILABLE_ERROR)
+ throw_exception (ex);
return info;
}
--
1.7.11.7
prev parent reply other threads:[~2014-01-16 18:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:21 Sergio Durigan Junior
2014-01-10 1:23 ` Yao Qi
2014-01-10 2:17 ` Yao Qi
2014-01-10 3:58 ` Sergio Durigan Junior
2014-01-10 10:57 ` Pedro Alves
2014-01-10 17:31 ` Sergio Durigan Junior
2014-01-10 18:57 ` Pedro Alves
2014-01-10 20:41 ` Sergio Durigan Junior
2014-01-13 17:12 ` Pedro Alves
2014-01-15 20:37 ` Sergio Durigan Junior
2014-01-16 18:20 ` Pedro Alves [this message]
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=52D822DC.8000205@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@redhat.com \
--cc=yao@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).