search for: compileunits

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

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

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

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

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

Hi, I have a question regarding the metadata for compileunit debug info. I find a few things in it a bit strange, but maybe there it is a reason for it to be that way that I just don't understand (but if that is the case I guess the documentation needs to be clearer). Consider this C program: "int X;" Compiled with "clang -g" it debug metadata along these lines:

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

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* compileUnit.getDirectory().str(); Thanks George -------------- next part -------------- An HTML attachment was scrubbed...

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

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

Evan Cheng wrote: > I don't think so. Contribution welcome! :-) LLVM debugging support > isn't anywhere near where it needs to be. > Well, here's a rough sketch of what I was thinking of: class DebugInfoBuilder { public: /// Constructor DebugInfoBuilder(); /// Return the type defined by llvm.dbg.anchor.type StructType * GetAnchorType() const; ///

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

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

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 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 >

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

Ping :) On Wed, Oct 9, 2013 at 5:22 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > 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

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

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 =

On Tue, Oct 15, 2013 at 10:05 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 9, 2013 at 5:22 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Wed, Oct 9, 2013 at 1:32 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> David, >>> >>> Thanks for reviewing!