search for: dwarfunit

Seems like something infinite-recursion like to me: $ clang --version clang version 6.0.0 (trunk 317833) Target: powerpc64le-unknown-linux-gnu $ clang -c test.ll warning: overriding the module target triple with powerpc64le-unknown-linux-gnu [-Woverride-module] ... #255 0x0000000012b07a78 llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*) ... So I'd say it reproduces. On Wed, Nov 15, 2017 at 6:20 AM, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Test on Mac, with not latest but trunk code. I get error below: > > $ clang -c test.ll > warning: overriding the mo...

Hello, I'm having this error and couldn't find a resolution from online, any help would be greatly appreciated: clang: /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't exist?"' failed. 0 clang 0x0000000001eaccd2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 clang 0x00000000...

...t; wrote: > >> Hello, >> >> I'm having this error and couldn't find a resolution from online, any >> help would be greatly appreciated: >> >> clang: >> /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: >> void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, >> llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that >> doesn't exist?"' failed. >> 0 clang 0x0000000001eaccd2 >> llvm::sys::PrintStackTrace(...

...>>>> I'm having this error and couldn't find a resolution from online, any >>>> help would be greatly appreciated: >>>> >>>> clang: >>>> /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: >>>> void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, >>>> llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't >>>> exist?"' failed. >>>> 0 clang 0x0000000001eaccd2 >...

Hi All, I have question about 'isUnsignedDIType' function on 'llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp' When we want to generate object file with dwarf debug format, clang can generates 'DW_ATE_lo_user' encoding for complex integer type as follow: "clang/lib/CodeGen/CGDebugInfo.cpp" llvm::DIType *CGDebugInfo::CreateType(const ComplexType *Ty) { ... if (Ty->isComplexI...

...43) by 0x55AE53E: llvm::object::resolveARM(llvm::object::RelocationRef, unsigned long, unsigned long) (RelocationResolver.cpp:250) by 0x502802B: llvm::DWARFDataExtractor::getRelocatedValue(unsigned int, unsigned int*, unsigned long*) const (DWARFDataExtractor.cpp:27) by 0x5071C2F: llvm::DWARFUnitHeader::extract(llvm::DWARFContext&, llvm::DWARFDataExtractor const&, unsigned int*, llvm::DWARFSectionKind, llvm::DWARFUnitIndex const*, llvm::DWARFUnitIndex::Entr y const*) (DWARFUnit.cpp:254) by 0x5070BAD: llvm::DWARFUnitVector::addUnitsImpl(llvm::DWARFContext&, llvm::DWARFObje...

+llvm-dev which got lost somehow > -----Original Message----- > From: Robinson, Paul > Sent: Thursday, March 31, 2016 10:33 PM > To: 'jingu kang' > Subject: RE: [llvm-dev] Question about 'isUnsignedDIType' function on > DwarfUnit.cpp > > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > jingu > > kang via llvm-dev > > Sent: Thursday, March 31, 2016 4:02 PM > > To: llvm-dev > > Subject: [llvm-dev] Question about ...

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those three DW...

...rge | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 9 февраля 2018 г. 18:35 Кому: George Rimar Копия: Robinson, Paul; llvm-dev at lists.llvm.org; Rafael Avila de Espindola Тема: Re: [llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges. Nah, doesn't look like it. Removed it (& the place I copied it from) in: r324738 Thanks! On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> wrote: >Totally fair call, sorry it took me a while...

Nah, doesn't look like it. Removed it (& the place I copied it from) in: r324738 Thanks! On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com> wrote: > >Totally fair call, sorry it took me a while to come back around to this - > added in r324702 > > Thanks ! Have a question: does it need "requres shell" ? > I tried without and it

...------------------------ > *От:* David Blaikie <dblaikie at gmail.com> > *Отправлено:* 9 февраля 2018 г. 18:35 > *Кому:* George Rimar > *Копия:* Robinson, Paul; llvm-dev at lists.llvm.org; Rafael Avila de > Espindola > *Тема:* Re: [llvm-dev] Collecting address ranges in > DWARFUnit::collectAddressRanges. > > Nah, doesn't look like it. Removed it (& the place I copied it from) in: > r324738 > > Thanks! > > On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com> > wrote: > >> >Totally fair call, sorry it took me...

>Totally fair call, sorry it took me a while to come back around to this - added in r324702 Thanks ! Have a question: does it need "requres shell" ? I tried without and it worked for me under windows (had to change check to CHECK: .{{\\|/}}test.cpp:2:51 though). And I see nothing special probably that might require shell I think. We use cd/rm/cp in LLD testcases without requiring

...hable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339): https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFUnit.cpp#L335 Object I used for debugging parser is following: t.ii: int a; clang++ -gsplit-dwarf -c t.ii -o t.o When parser tries to read this object it attemps to extract address ranges from dwo. When we don't give it .debug_str it fails to extract dwo name, exits early and "works&quot...

Totally fair call, sorry it took me a while to come back around to this - added in r324702 On Thu, Nov 16, 2017 at 3:47 PM Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > > wrote: > > >

...;class T> class Test { }; } $ clang++ -g -emit-llvm test1.cpp -S -o test1.ll $ clang++ -g -emit-llvm test2.cpp -S -o test2.ll $ llvm-link test1.ll test2.ll -S -o linked.ll $ llc linked.ll The last step raises an assertion error, assuming you have assertions enabled: llc: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:953: llvm::DIE* llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode*): Assertion `Ty == resolve(Ty.getRef()) && "type was not uniqued, possible ODR violation."' failed The initial introduction of the "test" namespace in test2.cpp seems to confuse clang -- tes...

Hi folks, I am trying to implement the C bindings API for DebugInfo::DWARF::DWARFDie. My goal is to have a C library that reads and parses DWARF debugging format (just like how llvm-dwarfdump does, but maybe more than just dumping debug info) I've started with creating C structure for DebugInfo::DWARF::DWARFContext which contains all DWARF DIEs in the object file. For this I used ```

There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations). In

David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the >> skeleton CU rather than the DWO CU. So it's quite possible that to get the >> address ranges covered by the CU one would

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const llvm::DIType * Ty, llvm::dwarf::Attribute Attribute) Line 768 C++ llvm::DwarfCompileUnit::applyVariableAttributes(const llvm::DbgVariable & Var, llvm::DIE & VariableDie) L...

...cpp -S -o test1.ll >> $ clang++ -g -emit-llvm test2.cpp -S -o test2.ll >> $ llvm-link test1.ll test2.ll -S -o linked.ll >> $ llc linked.ll >> >> The last step raises an assertion error, assuming you have assertions >> enabled: >> llc: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:953: llvm::DIE* >> llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode*): Assertion `Ty == >> resolve(Ty.getRef()) && "type was not uniqued, possible ODR violation."' >> failed >> >> The initial introduction of the "test" namespac...