From: Yao Qi <qiyaoltc@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] Use -fno-asynchronous-unwind-tables if C program is compiled without debug info on x86
Date: Wed, 20 Apr 2016 08:38:00 -0000 [thread overview]
Message-ID: <86wpnsiskw.fsf@gmail.com> (raw)
In-Reply-To: <57163425.1070505@redhat.com> (Pedro Alves's message of "Tue, 19 Apr 2016 14:35:33 +0100")
Pedro Alves <palves@redhat.com> writes:
> No sure about this. This is an ABI change on x86_64 -- the x86_64 ABI
> requires eh_frame.
This is because people want to unwind frames without using frame
pointer register (registers are very limited on x86), so different
tools, like glibc's backtrace and libunwind, can use eh_frame to unwind
correctly. Then, ABI requires eh_frame.
GDB is different, because it can still rely on the prologue unwinder if
no debug info. On the other hand, GDB prologue unwinder should be
tested in case that no debug info is produced by compiler. We just use
-fno-asynchronous-unwind-tables to produce binaries to exercise GDB, so
I don't worry about ABI incompliance.
>
> Should we instead add a new "nounwind" option, and a few
> prologue-unwinder-specific tests?
We don't know how prologue unwinder is used in each test case with
option "nodebug", so I am afraid we need to add "nounwind" to every
test case where option "nodebug" is used.
--
Yao (齐尧)
next prev parent reply other threads:[~2016-04-20 8:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 7:50 [PATCH 0/2] PR 19947: throw right exception in read_code and read_stack Yao Qi
2016-04-19 7:50 ` [PATCH 2/2] Throw NOT_AVAILABLE_ERROR in read_stack and read_code Yao Qi
2016-04-22 13:41 ` Pedro Alves
2016-05-04 14:08 ` Yao Qi
2016-04-19 7:50 ` [PATCH 1/2] Use -fno-asynchronous-unwind-tables if C program is compiled without debug info on x86 Yao Qi
2016-04-19 13:35 ` Pedro Alves
2016-04-20 8:38 ` Yao Qi [this message]
2016-04-22 12:30 ` Pedro Alves
2016-04-22 14:23 ` Yao Qi
2016-04-22 14:36 ` Pedro Alves
2016-04-22 16:05 ` Yao Qi
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=86wpnsiskw.fsf@gmail.com \
--to=qiyaoltc@gmail.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