[LLVMdev] Inlined functions

[David Blaikie]

On Mon, Mar 24, 2014 at 11:21 AM, RICHARD STUCKEY
<richard.stuckey at virgin.net> wrote:
> Hello, All,
>
> This is my first post to this mailing list.
>
> I am currently working on adding debug information generation to the front
> end of a compiler that uses LLVM.    The execution model for the compiled
> programs is that there are no function calls, and no stack - instead, all
> called functions are inlined (this is possible as the source language does
> not permit recursion).  However, the inlining is done by the F/E, so that
> LLVM sees only a single 'main' function.
>
> I can see no way of representing this inlining in the metadata being
> generated by the F/E: the DIBuilder class provides no methods for inlined
> functions, and the 'Source Level Debugging with LLVM' document has very
> information concerning inlining; e.g. there is this information
>
> "Here !12 is metadata providing location information. It has four fields:
> line number, column number, scope, and original scope. The original scope
> represents inline location if this instruction is inlined inside a caller,
> and is null otherwise. In this example, scope is encoded by !4, a subprogram
> descriptor. This way the location information attached to the intrinsics
> indicates that the variable X is declared at line number 2 at a function
> level scope in function foo."
>
> in the 'Object lifetimes and scoping' section, but little else.
>
> I do not see how to represent the inlining of complete functions in the
> metadata such that the generated DWARF debug information will contain DIEs
> with the DW_AT_inline attribute, abstract instances and concrete inlined
> instances, etc.,  which will be required to allow a debugger to re-construct
> a notional function call-chain for any given point in the code.
>
> Does anyone know how to do this?

One way to get into this might be to look at the result of running
Clang's IR through LLVM's inliner - and look at the resulting IR with
the debug info nodes attached, replicating that sort of output should
be a good start.

- David