RE: [PATCH 1/2, ver2] PowerPC, Fix-test-gdb.base-store.exp

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Andrew Burgess <aburgess@redhat.com> wrote:

>Sorry for being such a pain w.r.t. this patch.  Honestly, it's mostly
>because you touched infrun.c that I'm so interested here.
[...]
>And I'd like to see clearer details about which tests the infrun.c
>changes will fix.

Hi Andrew, as I suggested that particular infrun.c change
to Carl, let me add some background to what Carl replied.

This one-line change in infrun.c fixes a (potential) common-code
bug in existing code.  However, this bug is likely dormant on
all current platforms:

First of all, the bug only shows up on platforms where the
kernel uses a trampoline to dispatch *calls to* the signal
handler (not just *returns from* the signal handler).  Many
platforms use a trampoline for signal return, and that is
working fine, but the only platform I'm aware of that uses
a trampoline for signal handler calls is (recent kernels for)
PowerPC.  I believe the rationale for using a trampoline here
is to improve performance by avoiding unbalancing of the
branch predictor's call/return stack.

However, on PowerPC the bug is dormant as well as it is hidden
by *another* bug that prevents correct unwinding out of the
signal trampoline.  This is because the custom CFI for the
trampoline uses a register number (VSCR) that is not ever used
by compiler-generated CFI, and that particular register is
mapped to an invalid number by the current PowerPC DWARF
mapper.

Now, as Carl fixed the PowerPC DWARF mapper to fix some test
case regressions that showed up on POWER10, he added correct
mappings for all registers including VSCR.  This then caused
unwinding out of the signal trampoline to start working
correctly, which in turn exposed the pre-existing infrun.c bug
in handling signal call trampolines.

Now, that particular bug is that if the kernel uses a signal
call trampoline, infrun.c will see that the current PC is
in a frame that is an immediate child of the step frame (as
the trampoline frame unwinds to the step frame) - and then
incorrectly thinks that a *subroutine call* must have happened.
But we don't want to treat a signal handler invocation like
a subroutine call, in particular we want "nexti" to step
into it.  That's fixed by the one-line change.


Bye,
Ulrich