similar to: [LLVMdev] question

That's because instructions have a location associated with them, not a compile unit. -eric On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. > > George > > On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: >> >> Here is

Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) *string getFileDirectory*(*const* Instruction &I){ MDNode *MD = I.getMetadata("dbg"); DICompileUnit compileUnit(MD); return compileUnit.getDirectory().str(); } George On Wed, Oct 3, 2012 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > Without knowing the code that you've written

Yeah, It looks like I am doing exactly what's in Dwarf*.cpp files, yet I am getting blanks. George On Tue, Oct 2, 2012 at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote: > On Tue, Oct 2, 2012 at 11:00 AM, George Baah <georgebaah at gmail.com> wrote: > > Hi Guys, > > How does one get the directory of the compilation unit in llvm? > > I am using

Hmmm, but it has a getDirectory function. -G On Thu, Oct 4, 2012 at 3:50 PM, Eric Christopher <echristo at gmail.com> wrote: > That's because instructions have a location associated with them, not > a compile unit. > > -eric > > On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > > I used DILocation instead of DICompileUnit and

I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. George On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: > Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) > > *string getFileDirectory*(*const* Instruction &I){ > > MDNode *MD = I.getMetadata("dbg"); > > DICompileUnit

You should probably think of the DIFooBar constructors like reinterpret-casts, not "go find the thing I actually want" functions. If you hand DICompileUnit() a node that is not a compile-unit metadata node, it's not going to tell you that you goofed. If you _did_ have a CU metadata node, then DICompileUnit's getDirectory() would work just fine. But you don't. --paulr

Without knowing the code that you've written and the IR that you're running on I'm not sure what I can do to help you. -eric On Wed, Oct 3, 2012 at 9:32 AM, George Baah <georgebaah at gmail.com> wrote: > Yeah, It looks like I am doing exactly what's in Dwarf*.cpp files, yet I am > getting blanks. > > George > > On Tue, Oct 2, 2012 at 2:10 PM, Eric

On Tue, Oct 2, 2012 at 11:00 AM, George Baah <georgebaah at gmail.com> wrote: > Hi Guys, > How does one get the directory of the compilation unit in llvm? > I am using DICompileUnit but for some reason I am getting blanks > for the directory name. Here is my code ... > > MDNode *MD = I.getMetadata("dbg"); > > DICompileUnit compileUnit(MD); > > return

>From DwarfDebug.cpp: >/// GetOrCreateSourceID - Look up the source id with the given directory and >/// source file names. If none currently exists, create a new id and insert it >/// in the SourceIds map. This can update DirectoryNames and SourceFileNames >/// maps as well. >unsigned DwarfDebug::GetOrCreateSourceID(StringRef FileName, >

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

Hi Arsen, we are beyond what I understand about how metadata operates. Maybe Adrian or David knows. --paulr From: Arsen Hakobyan [mailto:hakobyan.ars at gmail.com] Sent: Friday, January 12, 2018 12:16 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org; David Blaikie Subject: Re: [llvm-dev] StripDeadDebugInfo for static inline functions. Just one update: the function causing the segmentation

Just one update: the function causing the segmentation fault is the following: 359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope *Scope) { 360 assert(Scope && Scope->getScopeNode()); 361 assert(Scope->isAbstractScope()); 362 assert(!Scope->getInlinedAt()); 363 364 const MDNode *SP = Scope->getScopeNode(); 365 366

Josh Matthews wrote: >> From DwarfDebug.cpp: > >> /// GetOrCreateSourceID - Look up the source id with the given directory and >> /// source file names. If none currently exists, create a new id and insert it >> /// in the SourceIds map. This can update DirectoryNames and SourceFileNames >> /// maps as well. >> unsigned

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

Thanks Paul, Hi Adrian and David I would really appreciate any comments, thoughts assumptions. If additional information is needed please let me know. Regards, Arsen On Sat, Jan 13, 2018 at 2:54 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > Hi Arsen, we are beyond what I understand about how metadata operates. > Maybe Adrian or David knows. > > --paulr > >

Hi Paul, Thanks for your response. Let me actually post more details visualizing my case. Assuming that can help. so the IR before the opt tool is running is: ; Function Attrs: nounwind define i16 @main() #0 !dbg !13 { entry: %retval = alloca i16, align 1 ... } ; Function Attrs: inlinehint nounwind define internal void @delay(i16 %d) #4 !dbg !69 { entry: %d.addr = alloca i16,

+ Adrian + David Hi Arsen, This sounds like a bug to me. Have you tried reproducing it on trunk? For instance, I see that the relation between DICompileUnit and DISubprogram was changed in the meantime (https://reviews.llvm.org/D19034 <https://reviews.llvm.org/D19034>). If this no longer occurs on master you could bisect the compiler to find the commit(s) that fix this and consider

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

The first patch seems fine, though the comment on the modified addDIEEntry function is a bit confusing: -/// addDIEEntry - Add a DIE attribute data and value. +/// addDIEEntry - Add a DIE attribute data and value. The form should be +/// a reference form: ref1, ref2, ref4, ref8, ref_udata, ref_addr, +/// or ref_sig8. A form can be chosen inside addDIEEntry. When the comment says "The form

On Wed, Oct 9, 2013 at 1:32 PM, Manman Ren <manman.ren at gmail.com> wrote: > > David, > > Thanks for reviewing! > > On Wed, Oct 9, 2013 at 11:36 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> Might be easier if these were on Phabricator, but here are some thoughts: >> >> 0001: >> This patch generally, while separated for