Implement gdbarch_stack_frame_destroyed_p for aarch64
authorTom Tromey <tromey@adacore.com>
Mon, 7 Mar 2022 21:06:09 +0000 (14:06 -0700)
committerTom Tromey <tromey@adacore.com>
Fri, 18 Mar 2022 17:01:43 +0000 (11:01 -0600)
commitda729c5ccde6eeccae539cbe51a285bc84769b3d
treee26b17b3329d87fb5335f666faa64e610cbb0564
parent0a30596cfad9cd221a81eea984b6fe3fabb20b95
Implement gdbarch_stack_frame_destroyed_p for aarch64

The internal AdaCore testsuite has a test that checks that an
out-of-scope watchpoint is deleted.  This fails on some aarch64
configurations, reporting an extra stop:

    (gdb) continue
    Continuing.

    Thread 3 hit Watchpoint 2: result

    Old value = 64
    New value = 0
    0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
    13    end Get_Val;

I believe what is happening here is that the variable is stored at:

    <efa>   DW_AT_location    : 2 byte block: 91 7c  (DW_OP_fbreg: -4)

and the extra stop is reported just before a return, when the ldp
instruction is executed:

   0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
   0x0000000040021648 <+208>: ret

This instruction modifies the frame base calculation, and so the test
picks up whatever memory is pointed to in the callee frame.

Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
this problem.

As usual with this sort of patch, it has passed internal testing, but
I don't have a good way to try it with dejagnu.  So, I don't know
whether some existing test covers this.  I suspect there must be one,
but it's also worth noting that this test passes for aarch64 in some
configurations -- I don't know what causes one to fail and another to
succeed.
gdb/aarch64-tdep.c