Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp

[Bruno Larsen <blarsen@redhat.com>]

On 22/09/2022 20:23, Carl Love via Gdb-patches wrote:
> GDB community:
>
> There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and
> gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar
> reasons on PowerPC.  It appears to me that the issues are with the
> tests and not with gdb itself. Both tests set breakpoints on *func
> where func is a function in the source file.  This is the fundamental
> issue with both tests.
>
> The test gdb.reverse/finish-reverse-bkpt.exp has the comment:
>
>     gdb_test "tbreak void_func" \
>         "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \
>         "set breakpoint on void_func"
>     gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*"
>
>     # We stop at the brekapoint on void_func, but breakpoint on
>     # *void_func will be set at the same place if function void_func doesn't
>     # have prologue.  One step forward to avoid this.
>     gdb_test "si"
>
>     gdb_test "break \*void_func" \
>         "Breakpoint $decimal at .*" \
>         "set breakpoint at void_func's entry"
>
> The comment about break point on void_func and breakpoint on *void_func
> being the same if there is no prolong is not true for all
> architectures.  Specifically PowerPC uses local and global entry
> points.  The statement "break *foo" sets the breakpoint at the address
> of the first instruction in the function where as "break foo" sets the
> breakpoint at the beginning of the function, i.e. after the prolog
> following the local entry point.  Specifically for this test the
> PowerPC assembly code is as follows:
>
>     void void_func ()
>     {
>         1000068c:   02 10 40 3c     lis     r2,4098                <-global entry point,
>                                                                      location of break *void_func
>         10000690:   00 7f 42 38     addi    r2,r2,32512
>         10000694:   f8 ff e1 fb     std     r31,-8(r1)             <-local entry point
>         10000698:   d1 ff 21 f8     stdu    r1,-48(r1)             <-prolog
>         1000069c:   78 0b 3f 7c     mr      r31,r1                 <-prolog
>       void_test = 1;                /* VOID FUNC */
>         100006a0:   00 00 00 60     nop                            <- location of break void_func
>         100006a4:   58 81 22 39     addi    r9,r2,-32424
>         100006a8:   01 00 40 39     li      r10,1
>         ....
>
> The test fails on PowerPC because the reverse execution never hits the
> breakpoint at *void_func because the function is called using the local
> entry point.  Thus gdb returns to the caller after it reaches the local
> entry point at address 10000694.  It does not continue executing back
> to the global entry point.  The global entry point is only used in
> special cases when the Table of Contents (TOC) pointer is not already
> setup in r2.
>
> The question is how to fix the test in general?
>
> 1) Changing the breakpoint on *void_func to void_func will cause both
> breakpoints to be the same regardless if there is a prolog.  That
> change would seem to invalidate the point of the test?
>
> 2) Disable the test for architectures where the assumption breakpoint
> on foo and breakpoint on *foo is the same except for a prolog.  The
> downside is we are missing testing of some gdb functionality.

Is there any way you can guarantee that the function will be called 
through the global entry point? Not just because this is the obvious 
solution, but because this would increase test coverage in GDB, seeing 
how reverse behaves on both possible entry points.

Another possibility would be to change the underlying GDB mechanism, and 
make `break *foo` place the breakpoint at the local entry point, since 
it seems to pass by the local entry point regardless of where it 
actually enters. From what I understand about reverse debugging, GDB 
already has to do something similar to reverse-next over functions, so 
it should be a doable solution.

A third possibility is trying to get the local entry point through 
disassembling the code and using `break *0xdeadbeef` instead. This would 
be the least intrusive solution, but I know nothing about different 
function entrypoints, so it might be too much work to be worth it.

>
> Is there another way to fix this test to run correctly on PowerPC?
>
>
> The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because
> it does a break on *callee.  Specifically,
>
>     set lineno [gdb_get_line_number "STEP INTO THIS CALL"]
>     gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call"
>
>     gdb_test "b \*callee" "" "set breakpoint at callee's entry"
>
>     set bpnum [get_integer_valueof "\$bpnum" 0]
>     gdb_test "reverse-next" \
>         "Breakpoint $bpnum, callee.*" \
>         "reverse-next over call trips user breakpoint at function entry"
>
>     gdb_test "up" \
>         ".*NEXT OVER THIS CALL.*" \
>         "stopped at the right callee call"
>
> In this case, it looks to me like changing the gdb_test to callee
> instead of *callee doesn't break the point of the test.  Making the
> change on PowerPC fixes the test.
>
> Does anyone see any issues with changing the breakpoint from *callee to
> calle for this test?
I think it does invalidate the test, because GDB will place a 
step-resume breakpoint at *callee, and the test wants specifically to 
look at a user breakpoint at the same instruction.

Cheers,
Bruno

>
> Thanks for the input and help fixing these tests on PowerPC.
>
>                                     Carl Love
>