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 <Ulrich.Weigand@de.ibm.com>]

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