similar to: [LLVMdev] Generating DWARF info

Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > Here is a patch that does just that. This does not work. I'm getting llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function ‘llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DICompileUnit)’: /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: error:

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at systemcall.org>wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums

OK so the problem is that the compiler sees '0' and can't decide whether its an integer or a null pointer of type Constant *. I guess the new functions will have to have slightly different names. On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > > Here is a patch

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at

On 12/06/2010 12:03 PM, Devang Patel wrote: > As I understand, you are not interested in 'how to use DIFactory'. Do you want > to know what are the fields of metadata to encode debug info for a local variable ? > That'd be > > !7 = metadata !{ > i32, ;; Tag (see below) > metadata, ;; Context > metadata, ;; Name > metadata, ;; Reference to

On Dec 4, 2010, at 1:16 PM, Bagel wrote: > On 12/03/2010 06:28 PM, Devang Patel wrote: >> We are working on a document. Here is current draft: >> http://wiki.llvm.org/Debug_Information >> >> - >> Devang > > While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions

On Mon, Dec 6, 2010 at 12:50 PM, Bagel <bagel99 at gmail.com> wrote: > On 12/06/2010 12:03 PM, Devang Patel wrote: > > As I understand, you are not interested in 'how to use DIFactory'. Do you > want > > to know what are the fields of metadata to encode debug info for a local > variable ? > > That'd be > > > > !7 = metadata !{ > >

On 12/03/2010 06:28 PM, Devang Patel wrote: > We are working on a document. Here is current draft: > http://wiki.llvm.org/Debug_Information > > - > Devang While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions (such as DIFactory::). My front-end can't use them because it is not

I've started investigating -O0 -g compile times with llvm-gcc, which are pretty important for people in development mode (e.g. all debug builds of llvm itself!). I've found some interesting things. I'm testing with mainline as of r52596 in a Release build and with checking disabled in the front- end. My testcase is a large C++ source file: my friend

On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though.

The old patch works, it's just that when you pass "0, 0, 0" for size, align and offset the compiler can't decide which method to call since "0" can be either a pointer or an integer. I can produce a new patch if you like, but I'm having trouble thinking of good names for the new methods. Alternatively, I suppose we could re-arrange the order of the parameters

On Mar 17, 2011, at 7:29 AM, Renato Golin wrote: > On 17 March 2011 13:48, Devang Patel <dpatel at apple.com> wrote: >> I think you are mistaken here. I maintain and support debug info for two front ends (llvm-gcc and clang). Go ahead and check svn archives for last one year and see how many times I had to update llvm-gcc FE. > > Hi Devang, > > First, I'm not

We don't currently apply any relocations (that I know of) for debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size =

On Jun 21, 2008, at 2:33 PM, Chris Lattner wrote: > > > $ sdiff -w 120 gcc.size llvm.size > Segment : 1495968 | Segment : 2211617 > Section (__TEXT, __text): 251661 | Section (__TEXT, __text): > 290873 > Section (__DWARF, __debug_frame): 82752 | Section (__DWARF, > __debug_frame): 80240 > Section (__DWARF, __debug_info): 671478 | Section

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 =

Here is a patch that does just that. On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote: > 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: > >>> > >>>