Re: [Dwarf-discuss] Proposal: Describe prologue and epilogue ranges
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
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
Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?
On Tue, 9 Mar 2021 at 10:13, Frank Ch. Eigler wrote:
>
> Hi, Andrew -
>
> On Tue, Mar 09, 2021 at 10:05:04AM -0500, Andrew Cagney via Dwarf-Discuss
> wrote:
> > [...]
> > This means that:
> > - for simple objects, local functions; and
> > - with link-time-optimization, everything except library interface functions
> > are fair game for ABI non-compliant call optimizations.
> >
> > Is anyone aware of a compiler doing this (I figure with LTO there's a
> > strong incentive)? And if so, how is this described to the debugger.
> > The ABI / calling-convention is no longer on hand for filling in the
> > blanks.
>
> FWIW, gcc does not leave ABI-dependent gaps in the DWARF generated for
> function parameters. First class location lists are given, whether or
> not they are in the ABI-governed locations, or whether they've been
> moved somewhere else, or whether they've been optimized out so that a
> consumer must recompute it somehow, or whether they exist at all.
So for instance, given a 64-bit big-endian ABI that left-packs large
structs vis:
struct {
uint64_t register_three;
uint8_t left_side_of_register_four;
};
but decides to pass left_side_of_register_four on the RHS would
generate a DW_OP_bit_piece DW_OP_piece (implied LHS).
> As I understand it, the location of *function return values* is
> however a gap in DWARF, and a consumer tool must resort to ABI specs.
> (Thus the elfutils dwfl_module_return_value_location() function.) I'm
> sure there's a Reason for this, but having worked on a consumer, it'd
> be handy if DWARF did explicitly identify the return value location
> too.
>
> - FChE
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-Discuss] compilers generating ABI non-compliant function calls?
Part of a typical Application Binary Interface is to specify the function calling convention. Several uses are: - ensuring function calls across interface boundaries work (function in one object calls function in second object) - the debugger supplementing the debug information describing the location of parameters - the debugger implementing inferior function calls Typically calls both between and within object files (DWARF compilation unit) follow the ABI (with exceptions for things like __mul, but good ABIs even defined those). Technically, however, only functions visible via an interface need comply with the ABI. This means that: - for simple objects, local functions; and - with link-time-optimization, everything except library interface functions are fair game for ABI non-compliant call optimizations. Is anyone aware of a compiler doing this (I figure with LTO there's a strong incentive)? And if so, how is this described to the debugger. The ABI / calling-convention is no longer on hand for filling in the blanks. (Keep in mind that this is different to adding an attribute to a function indicating it should follow a different calling convention - while different, it is still defined ahead of time). ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
