[Dwarf-Discuss] compilers generating ABI non-compliant function calls?

Michael Eager eager@eagercon.com
Wed Mar 10 17:42:40 GMT 2021


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.

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.

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.


-- 
Michael Eager



More information about the Dwarf-discuss mailing list