Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp

[Ulrich Weigand via Gdb-patches <gdb-patches@sourceware.org>]

Carl Love <cel@us.ibm.com> wrote:

>PowerPC has two entry points, local and global.  The test used to set
>the breakpoint for the function at the local entry point.  With your
>changes, the breakpoint is now being set at the global breakpoint
which
>is before the local breakpoint.  The function is actually entered at
>the local breakpoint thus gdb never "sees" the breakpoint that was
set.
>Specfically, here is the objdump for the test:

>00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
>    100006e0:   02 10 40 3c     lis     r2,4098                      <-
>Global entry point
>    100006e4:   00 7f 42 38     addi    r2,r2,32512
The local enty point is actually here:
>    100006e8:   f8 ff e1 fb     std     r31,-8(r1)
>    100006ec:   d1 ff 21 f8     stdu    r1,-48(r1)
>    100006f0:   78 0b 3f 7c     mr      r31,r1
>    100006f4:   00 00 00 60     nop                                  <-
>Local entry point
>    100006f8:   28 81 22 39     addi    r9,r2,-32472

Not here. This point might be the end of the prologue, which is a
separate question from the local vs. global entry point issue.

>Perhaps Ulrich has some ideas???

This:
+       gdb_breakpoint *$func
is nearly always wrong, and test cases shouldn't be using it.

I know that in the past, this construct was sometimes used with an
intended meaning of "set a breakpoint at the start of a function
without skipping the prologue", but it does *not* actually mean that.

The "*" operator tells the breakpoint logic to set a breakpoint on an
absolute address.  If followed by a symbol, that symbol's value is used
as that absolute address.  Now, on many platform, that symbol value
matches the address of the first instruction of a function, so the
"break *func" does more or less what's intended above.

But there are other platforms where this is not true, and the
relationship between the function symbol value and the address of the
first executed instruction is more complex.  This specifically applies
to targets that implement gdbarch_deprecated_function_start_offset
and/or gdbarch_skip_entrypoint.  (ppc64le uses the latter.)

Note that these are *independent* of prologue skipping, and on
platforms where it matters, they have to be used even when avoiding
prologue skipping, in order to correctly find the first instruction of
a function to set a breakpoint on.   "break *func" ignores this,
leading to failures on such platforms.


As I said initially, I think this construct should never be used in
test cases (at least not in scenerios where it is intended to set a
breakpoint that will actually be hit).

For this specific test, if the underlying problem is a bug in some
architecture's prologue parser, then ideally this bug simply should be
fixed.  If we need to actually avoid prologue skipping for some real
underlying reason, we should use a way that still handles function
start offsets and entrypoint skipping.  For example, in a function with
debug info including valid location lists, GDB will always avoid
prologue skipping.  We could also think of adding an explicit linespec
modifier that would allow to explicitly set a breakpoint on the first
instruction of a function without skipping prologue ...


Bye,
Ulrich