In many languages, the local variables in functions can have their lifetime
- or scope limited to a subset of a function. In the C family of languages,
+
In many languages, the local variables in functions can have their lifetimes
+ or scopes limited to a subset of a function. In the C family of languages,
for example, variables are only live (readable and writable) within the
source block that they are defined in. In functional languages, values are
only readable after they have been defined. Though this is a very obvious
- concept, it is also non-trivial to model in LLVM, because it has no notion of
+ concept, it is non-trivial to model in LLVM, because it has no notion of
scoping in this sense, and does not want to be tied to a language's scoping
rules.
In order to handle this, the LLVM debug format uses the metadata attached
- with llvm instructions to encode line nuber and scoping information.
- Consider the following C fragment, for example:
In order to handle this, the LLVM debug format uses the metadata attached to
+ llvm instructions to encode line nuber and scoping information. Consider the
+ following C fragment, for example:
@@ -811,7 +811,7 @@ DW_TAG_return_variable = 258
-nounwind ssp {
+define void @foo() nounwind ssp {
entry:
%X = alloca i32, align 4 ; [#uses=4]
%Y = alloca i32, align 4 ; [#uses=4]
@@ -867,68 +867,74 @@ declare void @llvm.dbg.declare({ }*, metadata) nounwind readnone
-This example illustrates a few important details about the LLVM debugging
- information. In particular, it shows how the llvm.dbg.declare intrinsic
- and location information, attached with an instruction, are applied
- together to allow a debugger to analyze the relationship between statements,
- variable definitions, and the code used to implement the function.
+This example illustrates a few important details about LLVM debugging
+ information. In particular, it shows how the llvm.dbg.declare
+ intrinsic and location information, which are attached to an instruction,
+ are applied together to allow a debugger to analyze the relationship between
+ statements, variable definitions, and the code used to implement the
+ function.
-
-
- call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7
-
-
This first intrinsic
+
+
+call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7
+
+
The first intrinsic
%llvm.dbg.declare
- encodes debugging information for variable X. The metadata,
- !dbg !7 attached with the intrinsic provides scope information for
- the variable X.
-
-
- !7 = metadata !{i32 2, i32 7, metadata !1, null}
- !1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
- !2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo",
- metadata !"foo", metadata !"foo", metadata !3, i32 1,
- metadata !4, i1 false, i1 true}; [DW_TAG_subprogram ]
-
-
Here !7 is a 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. It is null otherwise. In this example scope is encoded by
+
+
+!7 = metadata !{i32 2, i32 7, metadata !1, null}
+!1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
+!2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo",
+ metadata !"foo", metadata !"foo", metadata !3, i32 1,
+ metadata !4, i1 false, i1 true}; [DW_TAG_subprogram ]
+
+
Here !7 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
!1. !1 represents a lexical block inside the scope
!2, where !2 is a
- subprogram descriptor.
- This way the location information attched with the intrinsics indicates
- that the variable X is declared at line number 2 at a function level
- scope in function foo.
+ 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.
Now lets take another example.
-
-
- call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
-
-
This intrinsic
+
+
+call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
+
+
The second intrinsic
%llvm.dbg.declare
- encodes debugging information for variable Z. The metadata,
- !dbg !14 attached with the intrinsic provides scope information for
- the variable Z.
-
-
- !13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
- !14 = metadata !{i32 5, i32 9, metadata !13, null}
-
-
Here !14 indicates that Z is declaread at line number 5,
- column number 9 inside a lexical scope !13. This lexical scope
- itself resides inside lexcial scope !1 described above.
+
+
+!13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
+!14 = metadata !{i32 5, i32 9, metadata !13, null}
+
+
Here !14 indicates that Z is declaread at line number 5 and
+ column number 9 inside of lexical scope !13. The lexical scope
+ itself resides inside of lexical scope !1 described above.
+
+The scope information attached with each instruction provides a
+ straightforward way to find instructions covered by a scope.
-The scope information attached with each instruction provides a straight
- forward way to find instructions covered by a scope.