On Wed, Mar 10, 2021 at 9:51 AM Michael Eager via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote:
> On 3/9/21 7:05 AM, Andrew Cagney via Dwarf-Discuss wrote: > > 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. > > This is an instance of a more general issue: debugging optimized code. > > DWARF has ways to describe some of the optimizations which a compiler > can perform, such as inlining. This is because at least some of the > semantics of the process of inlining are well defined. Even then, a > debugger calling an inlined function is generally not possible, unless > there is a non-inlined instance. > Yep, and DWARF makes it clear to the consumer that this situation has occurred - the consumer can provide an informative error message to the user about the function having been inlined & so it is not callable. There are a range of optimizations which a compiler can perform as > long as the program performs as if the optimization was not done. > These include eliminated code, merged code, duplicated code, non-ABI > calls, non-ABI returns, and lots more. DWARF describes the > correspondence between source code and executable instruction, the > locations of arguments and variables, and how to walk the stack. > Fair enough - sounds like we're in agreement about the original question: Compilers do this (create non-ABI conforming functions) [and DWARF doesn't currently have a way to describe how to call such a function]. GCC and Clang/LLVM do describe these situations in somewhat different ways - but I don't think either would provide a strong basis on which to synthesize correct calls to these functions from a DWARF consumer. > This seems to be adequate to debug many optimized programs, even if it > is not a complete description of the optimizations. > > If you want a debugger to be able to call a function which has been > merged (partially or completely) into another function, or which has > a streamlined non-ABI compliant call/return sequence, DWARF does not > provide this information. There might be a way to describe this > piecemeal, addressing this one instance of the general issue of how > to debug optimized code. Or perhaps there is a more general way to > describe optimizations. Speculation beyond the original question: Given that it's a pretty common/core feature of a debugger to call functions, perhaps a start would be some way for the producer to communicate, via DWARF, that it has changed the ABI of a function and so the consumer should not try to synthesize calls to it. Providing much more functionality than that I think will amount to encoding the ad-hoc ABIs that compilers create in these situations (possible, but a fairly non-trivial proposal/enhancement to DWARF) This won't be complete, though - since I expect debuggers call functions that don't even have any DWARF description, by using the mangled name to determine the ABI - so compilers would probably still need some work to modify the function names to make them not accidentally communicate how they are to be called. (& maybe if that were fixed, there would be no need for a DWARF feature to flag such functions - instead it could be communicated in the mangling) - Dave
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
