Re: [PATCH 1/2] Use -fno-asynchronous-unwind-tables if C program is compiled without debug info on x86

[Pedro Alves <palves at redhat dot com>]

On 04/20/2016 09:37 AM, Yao Qi wrote:
> 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.

I believe unwind frames are also necessary for pthread cancellation
and thread_cleanup_push implemented in terms of gcc's
__attribute__ __cleanup__, in C programs.

> 
> GDB is different, because it can still rely on the prologue unwinder if
> no debug info. 

Which is heuristic and can (and does) thus fail sometimes.

> On the other hand, GDB prologue unwinder should be
> tested in case that no debug info is produced by compiler.

Though that's not testing what the compiler will normally output
with just "-On" and no -g.  That's what in part what I was trying
to convey -- the ABI change means we're not testing what
people normally use.

> We just use
> -fno-asynchronous-unwind-tables to produce binaries to exercise GDB, so
> I don't worry about ABI incompliance.

Right.

> 
>>
>> 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.

I think most, if not all, "nodebug" tests will be about no symbol info,
and aren't really about the unwinder at all.

I was suggesting new tests specific for the prologue unwinder,
not changing the existing tests.  E.g., just something simple that runs
to a function and does "backtrace" making sure the expected frames are
visible.

If we want to cover more cases, maybe do a test that single-steps through
some body of code, and issues backtrace at every single-step,
prologues/epilogues included, making sure "main" is always visible
in the backtrace.

We could actually have that test try "backtrace" with dwarf unwinding,
and then the same but with the prologue unwinder.

Whether forcing use of the prologue unwinder through compilation flags
is the best way, not sure.  A "maint set force-prologue-unwinder on" command
would make it easier to make sure we test what we intend to test on all
architectures, independent of program language, and independent
of architecture.  Plus, a test unit testing the prologue unwinder could
then conveniently make use of debug info.

(If such a test steps through dynamic symbol resolution / plts, then it's
likely that it can only really work with dwarf unwinding, though I think
it'd be a nice test to have and would likely expose bugs in glibc's
cfi markers in assembly code.)

Thanks,
Pedro Alves