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 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091201/fddd03f4/attachment.html>
Hi Talin,> 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.if I try to use gdb (version 7) with any large program compiled by llvm with debug info (such as cc1 built by bootstrap) then gdb instantly dies with a segmentation fault (and it doesn't even ask me if I want a core dump :) ). So it looks like there is something nasty going on in general... Ciao, Duncan.
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
On Wed, Dec 2, 2009 at 10:04 AM, Devang Patel <devang.patel at gmail.com>wrote:> 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 ? >I am pretty sure that it is - I've double checked the code and looked at the IR output. I did have a problem earlier where purely synthetic functions (trampoline functions generated by the compiler and so on) were being generated with the wrong DISubprogram (it wasn't reset from the previous function), and while that did cut down on the number of problems, it didn't completely eliminate them.> > > 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. ] >Right, I saw that, and planned on using it - the explanation you give is helpful. I want to make sure I understand the relationship between line number and context. If I have a DILocation that has a context that is not a compile unit, what is the line number relative to? My assumption is that it walks up the chain of contexts until it finds a compile unit, and the line number is relative to that.> - > 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 >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091202/8df8a86c/attachment.html>