[LLVMdev] Inlined functions
RICHARD STUCKEY
richard.stuckey at virgin.net
Mon Mar 24 11:21:20 PDT 2014
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>
More information about the llvm-dev
mailing list