[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