[Dwarf-discuss] Proposal: Describe prologue and epilogue ranges

[Andrew Cagney]

On Tue, 19 Mar 2024 at 10:44, Robinson, Paul <paul.robinson@sony.com> wrote:
>
>
> Andrew Cagney wrote:
>
> > > A single location description (which can be either simple or composite
> > > location descriptions) has the lifetime of its closest containing scope.
> > > The case we care about here is when that scope is a subprogram, and
> > > therefore the lifetime spans the entire subprogram. Pedantically, that
> > > lifetime includes prologue and epilogue ranges.
> > >
> > > It is common practice for unoptimized code to allocate local variables
> > > to a stack frame, and use that stack location in the single location
> > > description. Because the stack frame is not necessarily in a valid state
> > > during prologue or epilogue code, in practice, debuggers typically
> > assume
> > > that a single location description is not valid during a prologue or
> > > epilogue, although the DWARF spec does not explicitly say so (AFAIK).
> >
> > Does this problem extend to instructions within a statement where a
> > simple location can also be invalid?  For instance, given:
> >
> >     load r1 from i        # i++
> >     inc r1
> >  -> store r1 in i
> >
> > an attempt to modify "i" would be trashed when the store instruction is
> > executed
> >
> > I'm not sure if this should be mentioned in the standard though.
> > Perhaps this is covered by "... and it does not move during its
> > lifetime."
>
> I don't see this case as any different from any other assignment.
> "i" hasn't moved, it has been copied in order to do some computation.
> The assignment doesn't actually occur until the store is executed.
> In typical unoptimized code, you wouldn't stop between the "inc"
> and the "store."

So is the expectation that, between the prologue and epilogue, simple
locations are valid at statement boundaries.
And does this apply to optimized code such as:

    #1 j = i + 1
    load r1 from "i"
    store r1 + 1 in "j"
    #2 i = foo(i)
    call foo  # r1 is param/result
    #3 i++
    inc r1
    store r1 in "i"

at #1, "i"'s location list is memory
at #2, "i"s location is both r1 and memory
at #3, "i"'s location is only r1