search for: difil

I noticed that clang produces DIFiles that look like DIFile(filename: "src/test.c", directory: "/path/to/pwd") at first I thought this must be a bug, but this could also be a space-saving optimization to unique the redundant $PWD prefix of all paths. Is this a bug or a feature? -- adrian

...out. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at DwarfDebug::recordSourceLine, I see that DIFile scopes are not valid for source lines. 2) What is the proper DIScope for executable code that is not part of a source-level function? For example, suppose I have code that is used to generate the initializ...

...inson at sony.com> wrote: > > > > -----Original Message----- > > From: aprantl at apple.com [mailto:aprantl at apple.com] > > Sent: Thursday, November 29, 2018 12:02 PM > > To: llvm-dev > > Cc: David Blaikie; Robinson, Paul; Davide Italiano > > Subject: DIFile filenames containing directories > > > > I noticed that clang produces DIFiles that look like > > > > DIFile(filename: "src/test.c", directory: "/path/to/pwd") > > > > at first I thought this must be a bug, but this could also be a space-...

Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com...

...ny Leviant: > It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context || isa<DIFile>(Context) || isa<DICompileUnit>(Context)) > > However, I suggest talking to someone with in-depth debug info experience, as the problem > itself seems to be not related to LTO. The problem seems to be related to that but it *d...

...ope: !2, file: !3, type: !622, isLocal: false, isDefinition: true) !2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "RemObjects Island", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, retainedTypes: !4, globals: !5, imports: !703) !3 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global", directory: "/__windows_drive__c/ci/b/elements/1301/source/islandrtl/source") !4 = !{} !5 = !{!0, !6, !620, !635, !637, !639, !660, !669, !671, !673, !675, !680, !682, !684} !6 = !DIGlobalVariableExp...

...ut -fdebug-prefix-map, but... On Thu, Nov 29, 2018 at 1:07 PM Adrian Prantl <aprantl at apple.com> wrote: > Thanks for the feedback! Closely-related follow-up question: Is *this* a > bug? > > llvm/tools/clang/test/CodeGen/debug-prefix-map.c:33:27: > // CHECK-COMPILATION-DIR: !DIFile(filename: > "/var/empty{{[/\\]}}Inputs/stdio.h", directory: "/var/empty") > Yeah, that doesn't look quite right to me. The duplication of the directory in both the filename and directory... Well, I guess it could be read as "resolve the filename relative to thi...

Ok, I've done a bit more investigation. I found the module which declares broken DIE (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there: !2 = !DIFile(filename: "island.windows.elements", ... ... !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ... !5 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global", ... All subsequent DIEs reference file !2, except DICompileUnit (!4) which r...

...scope: !2, file: !3, type: !622, isLocal: false, isDefinition: true) !2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "RemObjects Island", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, retainedTypes: !4, globals: !5, imports: !703) !3 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global", directory: "/__windows_drive__c/ci/b/elements/1301/source/islandrtl/source") !4 = !{} !5 = !{!0, !6, !620, !635, !637, !639, !660, !669, !671, !673, !675, !680, !682, !684} !6 = !DIGlobalVariableExpres...

...0 is_stmt 0x0000000000000044 25 13 1 0 0 is_stmt prologue_end 0x0000000000000080 0 0 2 0 0 is_stmt 0x000000000000008b 0 0 2 0 0 is_stmt end_sequence the debug info is emitted by the DIBuilder like !3 = !DIFile(filename: "/folk/tmp/test/test.cpp", directory: "/folk/tmp/test") !45 = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_test.cpp", scope: !3, file: !3, type: !46, flags: DIFlagArtificial, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !2, retainedNodes:...

...ble-output 2>&1 | FileCheck %s define void @f1() !dbg !4 { unreachable } ; CHECK: DISubprogram attached to more than one function define void @f2() !dbg !4 { unreachable } !llvm.dbg.cu = !{!1} !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2) !2 = !DIFile(filename: "t.c", directory: "/path/to/dir") !3 = !{} !4 = distinct !DISubprogram(name: "foo", scope: !1, file: !2, unit: !1) Why? When two functions share the same DISubprogram attachment, the DWARF backend gets very confused and adds all attributes from all fun...

...direction. > OK I made 3 changes: -- changed isDefinition to true. (I'm also only generating debug info for definitions.) -- commented out the code that pushes parameter types to the arg list. (Still push the return type however.) -- changed the call that creates the subroutine type to use DIFile rather than DICompileUnit as the context param. It still segfaults however. :( I should mention that I don't actually know if the CreateSubprogram call is even related to the problem. I know that when I comment out the call, the segfault goes away - however, that just might mean that the pro...

...ST might contain other "FileIncludeDecl"/"MacroDecl" ASTs. These two new AST DECLs are not part of TranslationUnitDecl and are handled separately (see AST example below). In the LLVM IR, metadata debug info will be extended to support new DIs as well: "DIMacro", "DIFileInclude", and "MacroNode". The last, is needed as we cannot use DINode as a base class of "DIMacro" and DIFileInclude" nodes. DIMacro will contain: * type (definition/undefinition). * line number (interger). * name (null terminated string). *...

...File >> >> You don't need CU here. >> >>> >>> type= di.createBasicType   //long >> >> same, you don't need CU here. > > If I don't have a di.createCompileUnit.  di.createFile fails with this message. > > DIBuilder.cpp:59: llvm::DIFile > llvm::DIBuilder::createFile(llvm::StringRef, llvm::StringRef): > Assertion `TheCU && "Unable to create DW_TAG_file_type without > CompileUnit"' failed. > > Which had me scratching my head, If DIFile needs a CU it  would be an > argument to DIBuilder::.crea...

Hi, I am wondering if someone can guide me in adding metadata to IR which already contains some metadata. I am trying to add dbg.declare inst for a local variable I added to a function. I used the DIBuilder to build a DIVariable. When I try to compile llc fails with following message. llc: MCAsmStreamer.cpp:273: virtual void<unnamed>::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion

...vm.dbg.cu = !{!2} > > > > !0 = !{i32 2, !"Debug Info Version", i32 3} > > > > !1 = !{i32 1, !"ThinLTO", i32 0} > > > > !2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, > > retainedTypes: !4) > > > > !3 = !DIFile(filename: "f2", directory: "") > > > > !4 = !{!5} > > > > !5 = !DICompositeType(tag: DW_TAG_class_type, file: !3, flags: > > DIFlagFwdDecl, identifier: "SHARED") > > > > !6 = distinct !DISubprogram(unit: !2) > > > &gt...

...l only rely on DIDescriptor class hierarchy to manipulate debug > info. The classes in this hierarchy are light weight enough to pass > around as objects. The problem with that is that you can't do: DIDescriptor file = factory->CreateFile(...); You have to get the type of file to be DIFile. When creating a Subprogram, you can't pass a DIFile object, but only a DIDescriptor, so you have to: DIDescriptor* desc = &file; factory->CreateSubprogram(*desc, ...); Also, because they're not pointers, you can't use cast, as you would when passing arguments to IRBuilder....

...t.a + t.b; } $ cat bar.cpp #include "t.h" int foo(T t); int bar(T t) { return foo(t) * 2; } Looking forward, after refactoring ownership and uniquing and fixing up a few schema issues, I'd expect the above to link into something like the following: !0 = metadata DIFile(filename: "foo.cpp", directory: "/path/to") !1 = metadata DIFile(filename: "./t.h", directory: "/path/to") !2 = metadata DIFile(filename: "bar.cpp", directory: "/path/to") !3 = metadata DIBaseType(name: "short", size...

...imal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a DISubprogram as before. On Wed, Aug 13, 2014 at 7:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Aug 13, 2014 at 3:47 PM, Keno Fischer > <kfischer at college.harvard.edu> wrote: >> Sorry, I didn't have a small IR example and I was sure I wa...

...ST might contain other "FileIncludeDecl"/"MacroDecl" ASTs. These two new AST DECLs are not part of TranslationUnitDecl and are handled separately (see AST example below). In the LLVM IR, metadata debug info will be extended to support new DIs as well: "DIMacro", "DIFileInclude", and "MacroNode". The last, is needed as we cannot use DINode as a base class of "DIMacro" and DIFileInclude" nodes. DIMacro will contain: • type (definition/undefinition). • line number (interger). • name (null terminated string). •...