Re: [PATCH] Turn on LRA on all targets

["Maciej W. Rozycki" <macro@orcam.me.uk>]

On Thu, 15 Feb 2024, Paul Koning wrote:

> > On May 15, 2023, at 5:09 PM, Maciej W. Rozycki <macro@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.

 The MIPS heuristic unwinder continues living in GDB; I have extended it
to the microMIPS ISA at one point.  It has a major flaw though: the MIPS 
psABI uses a variable frame layout, with the frame maintained solely by 
software and with no fixed hardware frame pointer, so to analyse it in the 
absence of debug information the instruction sequence of the function's in 
question prologue has to be decoded to discover the location of individual 
frame slots.

 Consequently the more aggressive the compiler has become to schedule
function body instructions within a function's prologue the more lost the 
machine code interpreter has become.  Ultimately it would have to become a 
full-fledged CPU simulator to do its heuristics.  In reality it means the 
unwinder may fail to produce acceptable results, which will happen at any 
frequency between hardly ever to most often, depending on the exact 
circumstances.

 A mixed approach by interpreting lightweight PDR (Procedure Description 
Record) information inherited from the ECOFF Mdebug format combined with 
function prologue scanning might be more reliable, because in that case 
frame slot positions are known and the only unknown is the code locations 
they are initialised each at.  So all the prologue scanner has to know it 
is the store machine instructions and any that set a frame pointer from 
the stack pointer.  All the other instructions can be simply ignored.  And 
then only in the innermost frame, because any outer frames must have been 
fully set up already.  But I never got to implementing it and remnants of 
the PDR unwinder have long been removed from GDB.

 Conversely no heuristics is required to unwind VAX frames, because they 
are fixed in layout by hardware, fully self-described, and with the 
hardware frame pointer always available.  Therefore to unwind a VAX frame 
steps similar to those made by hardware on a function return (machine RET 
instruction) can simply be recreated from information produced by hardware 
at the function call and recorded in the stack frame and registers.  There 
is room reserved in the stack frame for a pointer to an exception handler 
even ("condition handler" in VAX-speak), preset to zero (a null pointer) 
by hardware at function entry.

 It does seem really attractive (and saves some storage space, which VAX 
hardware users will likely appreciate), but implies dedicated libgcc code 
as opposed to reusing common bits, which may or may not be welcome by the 
community for such an exotic corner case target.

  Maciej