llvm dev - Mar 2014 - [LLVMdev] Inlined functions

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*<http://llvm.org/docs/SourceLevelDebugging.html#format-subprograms>.
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?

      Regards,

            Richard Stuckey
<http://llvm.org/docs/SourceLevelDebugging.html#id25>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140324/06d1450e/attachment.html>

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