Re: [PATCH] Implement gdbarch_stack_frame_destroyed_p for aarch64

[Luis Machado <luis.machado@arm.com>]

Hi,

On 3/14/22 13:24, Tom Tromey wrote:
> 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.

The kind of which will change from run to run, not triggering the 
watchpoint in some cases?

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

Yeah. Anyway, other backends rely on this hook as well. So the patch is 
fine to me. As I've said before, I didn't see any regressions.

Thanks,
Luis