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

[Yao Qi <qiyaoltc@gmail.com>]

Pedro Alves <palves@redhat.com> writes:

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

It is quite common that gdb tests find some bugs of some thing which
isn't these tests about.  The test was written for feature A, but it may
find bugs in feature B or C.

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

That must be useful.  If debug infor is produced, it can be a good test
to compiler.

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

We had this idea too when we wrote aarch64 tracepoint support.  We
wanted to know which unwinder is chosen by GDB for a given frame.

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

I want to focus on handling unavailable memory in frame unwinder, so I
cannot do all of them above.  What I can do are:

 1. Name some unwinders, such as dwarf unwinders, prologue unwinders,
 sigtramp unwinders, stub unwinders, etc.  Other unwinders are nameless.
 2. Add a new maint command "maint set/show preferred-unwinder".  This
 command tell GDB to prefer a unwinder during frame unwinding.  If the
 unwinder can't be applied to the frame (sniffer fails), it is not chosen.
 3. Prefer different unwinders (dwarf vs. prologue) in the different
 runs of gdb.trace tests, like

 foreach_with_prefix unwinder { "dwarf" "prologue" } {
   gdb_test "maint set preferred-unwinder $unwinder"
   gdb_test "tfind start"
   .....
   gdb_test "tfind stop"
 }

 so that the PR 19947 can be reproduced.  I'll stop here.

 What I don't plan to do in the short term are:

 - Write a case, let GDB single-step through its body, including
   prologue, epilogue and its callees, and check "bt" can show the
   frames correctly with different unwinders.
 - Single-step through dynamic symbol resolution / plt, prefer "dwarf"
   unwinder, and check "bt" can show the frames correctly.

Is it OK to you?

-- 
Yao (齐尧)