Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call
On Fri, 7 Dec 2018 at 16:56, Jakub Jelinek via Dwarf-Discuss
wrote:
>
> On Fri, Dec 07, 2018 at 08:58:42AM -0800, Cary Coutant via Dwarf-Discuss
> wrote:
> > And that's another reason why on PA-RISC and Itanium we have the rule
> > that the unwind info for the PC of the instruction following the call
> > must be accurate. With that rule, we do not have to anticipate or
> > compensate for the consumer. One hack always begets another hack. (Of
> > course, if some debuggers were to subtract 1 despite that rule, we
> > would have to either compensate or declare them buggy.)
> >
> > Jakub complains that "the compiler would need to emit a nop after
> > every call, which an optimizing compiler is not willing to do." We're
> > not talking about *every* call, just the rare case of a no-return
> > call.
>
> They aren't that rare, and even if they would, that is still not enough.
> For proper debug info one needs to differentiate between the context inside
> of the call and the context right after the call, while in the %eax case
> that has been discussed it makes no difference, in others it does.
>
> Consider:
> void bar (void);
> void baz (int);
> int
> foo (void)
> {
> int a = 6;
> bar ();
> {
> long a = 5;
> baz (10);
> }
> return 10;
> }
> If you don't subtract one during unwinding and during the bar call look at
> foo's frame, then it would appear as if you are already at the baz call with
> the inner a variable in scope, but that shouldn't be in scope yet, and if
> user asks for value of a, he should see that 6 and its type should be int,
> not long.
To expand on CFI.
If one isn't subtracted then unwinding may not even work. Compilers,
while generating information to unwind thw 'PC' to the 'return
address', generate unwind information to restore the stack structure
to _before_ the call. This is because the SP immediately before and
immediately after the function call can be different.
For instance, on a VAX, the return instruction discards parameters on
the stack that were pushed before CALLS was executed something like:
push parameters
# SP includes parameter list
callS foo() -- pushes # parameters along with other stuff
# on return 'parameters' are gone
nop
https://www.computer.org/csdl/proceedings/afips/1978/5086/00/50860967.pdf
I've always wondered about generating zero-length location
descriptions (which currently are illegal) to handle these cases. It
would address Cary's 1-instruction call problem.
Andrew
___
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
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
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] 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
