> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki <ma...@orcam.me.uk> wrote:
>
> On Thu, 15 Feb 2024, Paul Koning wrote:
>
>>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki <ma...@orcam.me.uk> wrote:
>>>
>>> ...
>>>
>>> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
>>> frame is always fully described by the hardware and there is never ever a
>>> need for debug information to be able to decode any VAX stack frame (the
>>> RET machine instruction uses the stack frame information to restore the
>>> previous PC, FP, SP, AP and any static registers saved by CALLS).
>>
>> That would make sense; it's like the heuristic unwinder found in some
>> other targets (I remember the MIPS one, which worked fairly well and
>> allowed debugging without useable debug data).
>
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Fair enough, but what I meant is only that it's conceptually similar: unwind
based on the code and machine state, rather than auxiliary information like
debug data. And I think your point was that on VAX this is indeed a reliable
technique by virtue of the iSA. In fact, the standard way to do exeception
handling unwinding is part of the originail VAX architecture (via the otherwise
unused first word (I think) of the call frame).
paul
