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

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

[Carl Love]

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

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]

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
>

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]

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.

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
> 

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]

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

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

[Ulrich Weigand]

Luis Machado <luis.machado@arm.com> wrote:

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

I don't think this works.  The problem is that "b *func" is a weird
hack that combines two aspects: use of "func" as a value that at this
point is just a plain symbol table lookup; and use of "*" to set a
breakpoint at an explicitly specified absolute address.

Neither of these aspects is something we want to change on its own.
We do want a plain symbol, if used as a value, to return the
address that is in the symbol table.  Everything else would just
be confusing, and could also break things if "if ptr == func"
where "ptr" is a function pointer variable.

On the other hand, when using "b *<addr>" with some hard-coded
address, we actually want the breakpoint to be exactly there
and nowhere else; that is usually used by someone familiar with
the platform who want to set the breakpoint exactly there. (Or,
possibly, by clicking on "set breakpoint" in a GUI switched to
the assembly view.) Automatically moving this to a different
address would be weird, when the whole point of "*" is that it
*isn't* trying to be clever, unlike say "b func".

It is an unfortunate fact that these two properties, which are
each desired on their own, combine to yield an undesirable
effect when used as "b *func" on Power.  But I think the root
cause of this is that "b *func" is used here in a way that is
not justified by the actual specification of those features.

Actually, I'm not seeing much use of this particular construct
at all, outside of the GDB test suite.  And here, it is used
in the idiosyncratic manner of "do a 'b func' but just without
skipping the prolog", usually because of some GDB test suite
internal reason why we want to avoid prolog skipping just here.

It seems to me that the real fix would be some new syntax that
makes this goal explicit, maybe along the lines of
  b -entrypoint func

(It would still be preferable to me to investigate use of this
construct throughout the test suite to see if it is *really*
necessary or if the tests can simply be rewritten in a way
that they don't need the "skip prolog" feature anyway ...)

Bye,
Ulrich

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

[Carl Love]

Ulrich, Luis:

On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote:
> Luis Machado <luis.machado@arm.com> wrote:
> 
> > 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?
> 
> I don't think this works.  The problem is that "b *func" is a weird
> hack that combines two aspects: use of "func" as a value that at this
> point is just a plain symbol table lookup; and use of "*" to set a
> breakpoint at an explicitly specified absolute address.
> 
> Neither of these aspects is something we want to change on its own.
> We do want a plain symbol, if used as a value, to return the
> address that is in the symbol table.  Everything else would just
> be confusing, and could also break things if "if ptr == func"
> where "ptr" is a function pointer variable.
> 
> On the other hand, when using "b *<addr>" with some hard-coded
> address, we actually want the breakpoint to be exactly there
> and nowhere else; that is usually used by someone familiar with
> the platform who want to set the breakpoint exactly there. (Or,
> possibly, by clicking on "set breakpoint" in a GUI switched to
> the assembly view.) Automatically moving this to a different
> address would be weird, when the whole point of "*" is that it
> *isn't* trying to be clever, unlike say "b func".
> 
> It is an unfortunate fact that these two properties, which are
> each desired on their own, combine to yield an undesirable
> effect when used as "b *func" on Power.  But I think the root
> cause of this is that "b *func" is used here in a way that is
> not justified by the actual specification of those features.
> 
> Actually, I'm not seeing much use of this particular construct
> at all, outside of the GDB test suite.  And here, it is used
> in the idiosyncratic manner of "do a 'b func' but just without
> skipping the prolog", usually because of some GDB test suite
> internal reason why we want to avoid prolog skipping just here.
> 
> It seems to me that the real fix would be some new syntax that
> makes this goal explicit, maybe along the lines of
>   b -entrypoint func
> 
> (It would still be preferable to me to investigate use of this
> construct throughout the test suite to see if it is *really*
> necessary or if the tests can simply be rewritten in a way
> that they don't need the "skip prolog" feature anyway ...)

I looked at the suggestion from Luis.  In the end, I really didn't
think changing gdb to make the test work is really the best idea.  The
issue is that there are cases, as Ulrich said, where someone who knows
the details may actually want to set the breakpoint on the first
instruction.  If I change gdb, to fix the test by "adjusting" the
desired breakpoint then the user is no longer able to stop where they
want to.

I am not sure why the original test was concerned about the prolog. 
The original author doesn't seem to be around anymore.  I will think
about how to change the first test some more.

I don't see any issues with changing the second test to just break on
the function callee rather than *callee.  I will submit a patch to
change the second test.  

                               Carl 

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]

On 26/09/2022 17:30, Carl Love via Gdb-patches wrote:
> Ulrich, Luis:
>
> On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote:
>> Luis Machado <luis.machado@arm.com> wrote:
>>
>>> 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?
>> I don't think this works.  The problem is that "b *func" is a weird
>> hack that combines two aspects: use of "func" as a value that at this
>> point is just a plain symbol table lookup; and use of "*" to set a
>> breakpoint at an explicitly specified absolute address.
>>
>> Neither of these aspects is something we want to change on its own.
>> We do want a plain symbol, if used as a value, to return the
>> address that is in the symbol table.  Everything else would just
>> be confusing, and could also break things if "if ptr == func"
>> where "ptr" is a function pointer variable.
>>
>> On the other hand, when using "b *<addr>" with some hard-coded
>> address, we actually want the breakpoint to be exactly there
>> and nowhere else; that is usually used by someone familiar with
>> the platform who want to set the breakpoint exactly there. (Or,
>> possibly, by clicking on "set breakpoint" in a GUI switched to
>> the assembly view.) Automatically moving this to a different
>> address would be weird, when the whole point of "*" is that it
>> *isn't* trying to be clever, unlike say "b func".
>>
>> It is an unfortunate fact that these two properties, which are
>> each desired on their own, combine to yield an undesirable
>> effect when used as "b *func" on Power.  But I think the root
>> cause of this is that "b *func" is used here in a way that is
>> not justified by the actual specification of those features.
>>
>> Actually, I'm not seeing much use of this particular construct
>> at all, outside of the GDB test suite.  And here, it is used
>> in the idiosyncratic manner of "do a 'b func' but just without
>> skipping the prolog", usually because of some GDB test suite
>> internal reason why we want to avoid prolog skipping just here.
>>
>> It seems to me that the real fix would be some new syntax that
>> makes this goal explicit, maybe along the lines of
>>    b -entrypoint func
>>
>> (It would still be preferable to me to investigate use of this
>> construct throughout the test suite to see if it is *really*
>> necessary or if the tests can simply be rewritten in a way
>> that they don't need the "skip prolog" feature anyway ...)
> I looked at the suggestion from Luis.  In the end, I really didn't
> think changing gdb to make the test work is really the best idea.  The
> issue is that there are cases, as Ulrich said, where someone who knows
> the details may actually want to set the breakpoint on the first
> instruction.  If I change gdb, to fix the test by "adjusting" the
> desired breakpoint then the user is no longer able to stop where they
> want to.
>
> I am not sure why the original test was concerned about the prolog.
> The original author doesn't seem to be around anymore.  I will think
> about how to change the first test some more.

 From what I could see in the comments of the test, the problem was that 
reverse-finishing out of the function would ignore breakpoints that were 
set before the prologue.

In case you aren't familiar with how GDB does a reverse-finish (and 
sorry if you are), it decides what is the first instruction executed in 
the current frame, places a breakpoint there, and reverse-continues 
until that breakpoint is hit. GDB then removes that breakpoint and does 
a reverse-stepi to leave the function call.

If there was already a user breakpoint at that instruction, GDB should 
_not_ do the reverse-stepi. For this test, it seems imperative that the 
breakpoint is placed before the prologue, since it is where GDB would 
place the step-resume-breakpoint that reverse-finish uses.

>
> I don't see any issues with changing the second test to just break on
> the function callee rather than *callee.  I will submit a patch to
> change the second test.

Same goes for the second test. It explicitly states that GDB was 
removing the user-placed breakpoint if it was placed at the exact same 
instruction as step-resume-breakpoint would be hit, so moving the 
breakpoint to after the prologue would render the test useless, as the 
bug conditions wouldn't be met anymore.

What you probably want to do in both cases is find a way to get the 
addresses of the functions and set a breakpoint there as "b *(address)" 
instead, though I'm not sure how I'd suggest you do it.

Cheers,
Bruno

>
>                                 Carl
>