Re: [PATCH] Implement gdbarch_stack_frame_destroyed_p for aarch64

[Tom Tromey <tromey@adacore.com>]

Luis> Are the passing/failing runs using different compiler versions?

Nope.

Luis> If the
Luis> variable no longer exists, then having a stale location like that
Luis> seems wrong. Can you pinpoint what is different from a passing test
Luis> and a failing one? GDB version, compiler version, different binary?

I didn't dig quite this deep but I think it's different memory contents
in the caller's stack frame.

Luis> These hooks seem to take care of functions without debuginfo, so they
Luis> tend to walk instruction by instruction to figure things out.

No, this is a case with full debuginfo.  What's happening is that the
DWARF for the callee describes the location of a variable as relative to
the stack frame:

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

However, at the end of the callee, there's an 'ldp' instruction -- which
resets the stack pointer.  So now, that variable's location description
points to an offset relative to the caller's frame.  However, this is
clearly incorrect, because the caller and the callee generally will not
agree on the relative location of anything in their frames.

Basically, this is a kind of epilogue detection.  It might be better if
the compiler told gdb about this (but it doesn't) or if variable
locations ended at the 'ldp' (but they don't).

Tom