[LLVMdev] A few more source level debugging questions
Devang Patel
devang.patel at gmail.com
Wed Dec 2 10:04:51 PST 2009
On Tue, Dec 1, 2009 at 10:56 PM, Talin <viridia at gmail.com> wrote:
> So, based on the info that I got from Devang, I was able to solve the
> problem with the duplicate assembly symbols, although I still don't quite
> understand why it was generating erroneous metadata in the first place. For
> example, through trial and error I discovered that the problem disappeared
> if I passed my DICompileUnit to CreateLocation() rather than my
> DISubprogram, but I don't know why.
The immediate lexical scope covering the location is the right answer.
Is your DISubprogram describing correct function ?
> The new API introduces a number of new parameters in DIFactory where I am
> not sure what the correct value to pass is. CreateLocation() is one example
> - I don't know if the context should be the compile unit, or the
> subprogram/region. The latter makes more sense, but is somewhat inconvenient
> in the face of templates, macros, where you have generated code within a
> function whose original source lines are from a different source file. It
> means that a source location (which is attached to every expression node)
> can't consist of merely [file, offset, length] but now has to carry other
> contextual baggage around as well, since conceivably any subtree of an
> expression could originate from outside the function.
DWARF specification describes how to handle macros and we are not at
all attempting to encode macros. However, we have a way (recently
introduced) way to encode situation where code from original source
code is found at another location.
The fourth parameter in DILocation describes location where the code
is copied/expanded. For example, if you have code at line no. 21 from
source file A which is copied (or expanded) at line no. 41 in source
file B and line no. 51 in source file C then
!1 = ... CompileUnit for source file A
!2 = ... CompileUnit for source file B
!3 = ... CompileUnit for source file C
!11 = metadata !{i32 21, i32 0, metadata !1, null } ; <-- Original
location of the code
...
!21 = metadata !{i32 41, i32 0, metadata !2, null } ; <--- source
location in file B
!22 = metadata !{i32 21, i32 0, metadata !1, !21 } ; <--- Code from
A:21 is copied at B:41
...
!31 = metadata !{i32 51, i32 0, metadata !3, null } ; <--- source
location in file B
!32 = metadata !{i32 21, i32 0, metadata !1, !31 } ; <--- Code from
A:21 is copied at C:51
[ Here !1, !2 and !3 may refer to appropriate DISubprogram or DILexicalBlock. ]
-
Devang
> Alternatively, passing
> in the compile unit makes sense, except that now there's no way to tell the
> IRBuilder about regions.
> Also, even though my code now assembles correctly, gdb gets very unhappy
> when I try to debug it - it prints
> "/build/buildd/gdb-7.0/gdb/dwarf2-frame.c:983: internal-error: Unknown CFA
> rule." and then asks me if I want to generate a core file of gdb.
> --
> -- Talin
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
--
-
Devang
More information about the llvm-dev
mailing list