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

[Andrew Cagney via Dwarf-discuss]

On Tue, 19 Mar 2024 at 10:44, Robinson, Paul  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
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Robinson, Paul via Dwarf-discuss]

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

--paulr
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Cary Coutant via Dwarf-discuss]

On Mon, Mar 18, 2024 at 2:06 PM Robinson, Paul via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> After today's call, hearing some viewpoints and hopefully learning a
> few things, I thought I'd take a stab at reframing 240108.1. (Without
> once mentioning CFI!) It ended up becoming an alternative proposal,
> but I'm fine with Zoran taking it over if he wants to.
>
> # Describe prologue and epilogue ranges
>

I've added this as Issue 240318.1
.

-cary
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Andrew Cagney via Dwarf-discuss]

On Mon, 18 Mar 2024 at 17:06, Robinson, Paul via Dwarf-discuss
 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."

> ## Overview
>
> A stopping point might occur during a prologue or epilogue range, which
> means single location descriptions for subprogram-scope objects might
> not be valid.
>
> - It would be good if the DWARF spec actually said single location
> descriptions were not necessarily valid in those ranges. This is simply
> codifying existing practice.
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Robinson, Paul via Dwarf-discuss]

After today's call, hearing some viewpoints and hopefully learning a
few things, I thought I'd take a stab at reframing 240108.1. (Without
once mentioning CFI!) It ended up becoming an alternative proposal,
but I'm fine with Zoran taking it over if he wants to.

# Describe prologue and epilogue ranges

## Background

### Stopping Points

Ordinarily, a source-level debugger will prefer to pause execution of a
program at instructions identified by the compiler as good places to do
so. These include instructions flagged as `is_stmt`, `prologue_end`, or
`epilogue_begin`. A user expects debug info such as source coordinates
and variable locations to be sensible and useful at those points.

It is entirely possible for execution to pause at other instructions.
There are a number of possible reasons for this.

- The user has chosen to single-step instructions rather than statements.
- The user has requested a breakpoint at a specific instruction that
happens not to have any of the above flags.
- An asynchronous exception has occurred and the debugger intercepted it.
- The program has crashed and the user is looking at a core dump.

This list is not exhaustive.

Let's call the instruction where a debugger has paused execution (or
the instruction where a crash was triggered) a "stopping point."

### Prologue/Epilogue Ranges

In DWARF v3 thru v5, a subprogram's prologue(s) and epilogue(s) are
described indirectly by the line table. A prologue generally consists
of all instructions from an entry point up to the first executed
instruction that is flagged as `prologue_end`. An epilogue generally
consists of all instructions from an instruction flagged as
`epilogue_begin` to where the subprogram returns to its caller. These
groups of instructions implicitly form ranges. (These ranges might be
empty.)

A subprogram might have multiple prologues if it has multiple entry
points; more often, it might have multiple epilogues if it has multiple
exit or return points. In particular, when there are multiple epilogues
it is not necessarily clear when an epilogue ends and the next basic
block (which might not be part of any epilogue) begins. (Even in the
case of a single epilogue, a cold but functional basic block might be
placed after the epilogue.)

Due to optimization, prologue or epilogue instructions might be mixed
with other instructions, so in practice prologue and epilogue ranges
might not be contiguous. DWARF does not have a way to describe these
non-contiguous prologue and epilogue ranges. Compilers typically have
various heuristics to pick stopping points for optimized prologue and
epilogue ranges.

### Single Location Descriptions

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

## Overview

A stopping point might occur during a prologue or epilogue range, which
means single location descriptions for subprogram-scope objects might
not be valid.

- It would be good if the DWARF spec actually said single location
descriptions were not necessarily valid in those ranges. This is simply
codifying existing practice.
- It would be good if debuggers could reliably identify prologue and
epilogue ranges.

The proposal adds text that excludes prologues and epilogues from the
implicit range of a subprogram-scope object, and adds a register to the
line-table state machine to identify prologues and epilogues.

Unlike `prologue_end` and `epilogue_begin`, the new `prologue_epilogue`
register is "sticky" in that it is not automatically reset on every
row of the line table. At an entry point, it must be set explicitly to
indicate the beginning of a prologue; it is automatically reset by the
DW_LNS_set_prologue_end. In an epilogue, it is automatically set by
DW_LNS_set_epilogue_begin, and reset by DW_LNE_end_sequence. This means
a function with one contiguous prologue and one contiguous epilogue,
terminated by `end_sequence`, the line-number program needs only one
new opcode to support `prologue_epilogue`.

Note: I have not tried to determine whether this minimizes size in
practice. It might be that prologues and/or epilogues typically occupy
only one row of the line table, in which case having the flag reset on
every row might take up less space.

## Proposed Changes

In Section 2.6 "Location Descriptions" modify the last sentence of
item