From: Yao Qi <qiyaoltc@gmail.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: <gdb-patches@sourceware.org>, <palves@redhat.com>
Subject: Re: [PATCH 1/4] Teach arm unwinders to terminate gracefully
Date: Fri, 12 Feb 2016 14:46:00 -0000 [thread overview]
Message-ID: <86io1ung0a.fsf@gmail.com> (raw)
In-Reply-To: <1452188697-23870-2-git-send-email-antoine.tremblay@ericsson.com> (Antoine Tremblay's message of "Thu, 7 Jan 2016 12:44:54 -0500")
Antoine Tremblay <antoine.tremblay@ericsson.com> writes:
Hi Antoine,
> The reason for this is that the target's stack pointer is unavailable
> when examining the trace buffer. What we are seeing is due to the
> 'tfind' command creating a sentinel frame and unwinding it. If an
> exception is thrown, we are left with the sentinel frame being displayed
> at level #-1. The exception is thrown when the prologue unwinder tries
> to read the stack pointer to construct an ID for the frame.
>
> This patch fixes this and similar issues by making all the arm unwinders
> catch NOT_AVAILABLE_ERROR exceptions when either register or memory is
> unreadable and report back to the frame core code with UNWIND_UNAVAILABLE.
>
> Note this commit log adapted from 7dfa3edc033c443036d9f2a3e01120f7fb54f498
> which fixed a similar issue for aarch64.
It is right to follow aarch64 patch, but I am wondering whether we can
do it better.
Nowadays, the unwind termination due to unavailable memory is handled in
unwinders in each arch backend. However, as we support more and more
arch for tracepoint, can we handle the unwind termination in target
independent code?
The initial work of unwind termination due to unavailable memory was
done by Pedro https://www.sourceware.org/ml/gdb-patches/2011-02/msg00611.html
in a way that each unwinder was taught to terminate with
UNWIND_UNAVAILABLE. At that moment, only x86 supports tracepoint, so it
was reasonable to handle UNWIND_UNAVAILABLE inside unwinders of one arch. Now,
the situation changes, because we have more and more arch need
tracepoint support, if we can handle UNWIND_UNAVAILABLE in the callers
of each unwinder, each unwinder doesn't have to worry about the
unavailable at all. In fact, GDB has done that way when calling unwinder->sniffer,
in frame_unwind_try_unwinder
TRY
{
res = unwinder->sniffer (unwinder, this_frame, this_cache);
}
CATCH (ex, RETURN_MASK_ERROR)
{
if (ex.error == NOT_AVAILABLE_ERROR)
{
/* This usually means that not even the PC is available,
thus most unwinders aren't able to determine if they're
the best fit. Keep trying. Fallback prologue unwinders
should always accept the frame. */
do_cleanups (old_cleanup);
return 0;
}
throw_exception (ex);
}
END_CATCH
we can wrap methods of 'struct frame_unwind' with try/catch, and handle
NOT_AVAILABLE_ERROR properly. In this way, each unwinder doesn't have
to worry about unavailable memory at all.
Pedro, what do you think? Did you try this approach in the rest of 9
different ways :) (you said you "implemented this differently in about
10 different ways" in your email) ?
--
Yao (齐尧)
next prev parent reply other threads:[~2016-02-12 14:46 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 17:45 [PATCH 0/4] Support tracepoints for ARM linux in GDBServer Antoine Tremblay
2016-01-07 17:45 ` [PATCH 1/4] Teach arm unwinders to terminate gracefully Antoine Tremblay
2016-02-12 14:46 ` Yao Qi [this message]
2016-02-24 17:57 ` Antoine Tremblay
2016-02-25 11:44 ` Pedro Alves
2016-02-25 13:15 ` Antoine Tremblay
2016-02-26 9:12 ` Yao Qi
2016-02-26 12:26 ` Antoine Tremblay
2016-02-26 14:25 ` Yao Qi
2016-02-26 20:10 ` Antoine Tremblay
2016-04-06 15:54 ` Yao Qi
2016-04-06 16:30 ` Pedro Alves
2016-04-07 16:33 ` Yao Qi
2016-05-04 16:24 ` Yao Qi
2016-01-07 17:45 ` [PATCH 4/4] Support tracepoints for ARM linux in GDBServer Antoine Tremblay
2016-01-07 17:45 ` [PATCH 2/4] Use the target architecture when encoding tracepoint actions Antoine Tremblay
2016-02-06 20:58 ` Marcin Kościelnicki
2016-02-11 13:02 ` Pedro Alves
2016-02-11 13:21 ` Antoine Tremblay
2016-01-07 17:45 ` [PATCH 3/4] Enable tracing of pseudo-registers on ARM Antoine Tremblay
2016-02-12 15:14 ` Yao Qi
2016-02-12 15:54 ` Marcin Kościelnicki
2016-02-15 10:27 ` Yao Qi
2016-02-15 10:57 ` Pedro Alves
2016-02-15 14:46 ` [PATCH v2] " Antoine Tremblay
2016-02-19 16:33 ` Antoine Tremblay
2016-02-19 19:29 ` [PATCH v3] " Antoine Tremblay
2016-02-19 20:06 ` [PATCH v4] " Antoine Tremblay
2016-02-19 20:22 ` [PATCH v3] " Pedro Alves
2016-02-19 20:32 ` Antoine Tremblay
2016-02-22 11:51 ` Yao Qi
2016-02-22 16:51 ` Antoine Tremblay
2016-02-24 18:11 ` Pedro Alves
2016-02-24 18:21 ` Marcin Kościelnicki
2016-02-24 18:33 ` Pedro Alves
2016-02-24 18:55 ` Antoine Tremblay
2016-02-24 19:02 ` Pedro Alves
2016-02-24 19:02 ` Antoine Tremblay
2016-02-23 19:34 ` Antoine Tremblay
2016-02-24 18:20 ` Pedro Alves
2016-02-24 18:47 ` Antoine Tremblay
2016-02-23 19:41 ` [PATCH v5] " Antoine Tremblay
2016-02-24 19:12 ` Pedro Alves
2016-02-24 19:25 ` Antoine Tremblay
2016-02-25 10:35 ` Yao Qi
2016-02-25 15:33 ` [PATCH v6] " Antoine Tremblay
2016-02-25 17:59 ` Pedro Alves
2016-02-25 18:19 ` Antoine Tremblay
2016-02-26 8:34 ` Yao Qi
2016-02-26 13:00 ` Antoine Tremblay
2016-02-26 13:03 ` [PATCH v7] " Antoine Tremblay
2016-02-26 14:14 ` Yao Qi
2016-02-26 14:57 ` Antoine Tremblay
2016-02-26 14:59 ` [PATCH v8] " Antoine Tremblay
2016-02-26 15:57 ` Yao Qi
2016-02-26 17:45 ` Antoine Tremblay
2016-01-11 12:17 ` [PATCH 0/4] Support tracepoints for ARM linux in GDBServer Yao Qi
2016-01-11 12:56 ` Antoine Tremblay
2016-01-11 13:41 ` Yao Qi
2016-04-26 19:11 ` Antoine Tremblay
2016-04-27 8:00 ` Yao Qi
2016-04-27 12:07 ` Antoine Tremblay
2016-04-27 13:57 ` Yao Qi
2016-04-27 14:41 ` Antoine Tremblay
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=86io1ung0a.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=antoine.tremblay@ericsson.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