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

[Luis Machado <luis.machado@arm.com>]

On 9/23/22 11:48, Luis Machado via Gdb-patches wrote:
> Hi Carl,
> 
> gdbarch has a hook to adjust the breakpoint address (gdbarch_adjust_breakpoint_address). Can this be used to bend commands
> like "b *func" so they behave the same as other architectures?
> 
> Alternatively, you may need to conditionally (for powerpc) walk through instructions and locate
> the correct address for the breakpoint.

Also, "break *func" is a fairly common command for users to issue when they want to stop exactly at the address of func.

Even though this is not technically always true, I think it is still pretty intuitive to expect that it will work. Should GDB
issue a warning of some kind so users are aware this doesn't work for power?

It would also help you track down testcases that expect this to work, and maybe some others that just happen to work but may break
in the future.

> 
> On 9/22/22 19: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 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?
>>
>> Thanks for the input and help fixing these tests on PowerPC.
>>
>>                                     Carl Love
>>
>