similar to: [LLVMdev] More on dwarf debugging

When developing an LLVM-based frontend, is there a way to automatically verify that the DWARF metadata being emitted is correct? Specifically, I'd like to be able to write some sort of unit test that will fail if the DWARF is invalid. I don't just want to test whether the LLVM metadata statements are well-formed - if I make a change that will cause lldb or gdb to barf, I would like to have

On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > > I've been trying to track down the problem with the DWARF info that is > being emitted by my front end, which has been broken for about a month now. > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X:

I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin

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 Mar 31, 2011, at 12:57 AM, Talin wrote: > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > >> I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb

One problem that has been vexing me of late: It seems that whenever I run into a problem that requires debugging one of my programs in gdb, before I can do that I have to fix my frontend's broken generation of debugging info. The code that generates debugging information is quite fragile - you have to generate metadata for each of your files, classes, and functions, and do so without error,

On Thu, Mar 31, 2011 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 31, 2011, at 12:57 AM, Talin wrote: > > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Mar 29, 2011, at 7:29 PM, Talin wrote: >> >> I've been trying to track down the problem with the DWARF info that is >> being

On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > > I've been trying to track down the problem with the DWARF info that is > being emitted by my front end, which has been broken for about a month now. > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X:

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 >

Talin, If there is a magic wand, I would be interested to know! DIDescriptor.Verify() is not suitable for you needs. It checks structure of encoded debug info after optimizer has modified the IR. Its main goal is inform Dwarf writer, at the end of code gen, which IR construct it should ignore. If you want to test code gen you have to link compiled code and run it regularly. That's what

On Mar 29, 2011, at 7:29 PM, Talin wrote: > I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin

Could dwarfdump --verify be used to check the debug info? - Jan ________________________________ From: Devang Patel <dpatel at apple.com> To: Talin <viridia at gmail.com> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Sent: Thu, March 17, 2011 9:41:10 AM Subject: Re: [LLVMdev] Writing unit tests for DWARF? Talin, If there is a magic wand, I would be interested

Talin, You're developing your own language and tool sets, it brings fresh perspective in our predominately C orientated environment, which is good. On Apr 1, 2011, at 8:12 PM, Talin wrote: > Is this a limitation of DWARF or of the LLVM generator? Neither, IMO. My own reading of DWARF did not find clear wording on this subject. I am not even sure if it is just a darwin gdb implementation

One of my unit tests has been failing recently, and the odd thing is that when I attempt to debug it in gdb, it causes a segfault: $ gdb test/stdlib/HashMapTest GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO

On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > > On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > >> I recently started getting this error when I try to debug my LLVM-compiled >> program in GDB: >> >> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c >> [in module

On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB:

I recently started getting this error when I try to debug my LLVM-compiled program in GDB: Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c [in module /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] I'm not sure if it's something I did or not. Is there any way to track down the cause of this error? The hex addresses in the error message are

On Sat, Apr 2, 2011 at 11:03 PM, Talin <viridia at gmail.com> wrote: > > > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Mar 29, 2011, at 7:29 PM, Talin wrote: >> >> I've been trying to track down the problem with the DWARF info that is >> being emitted by my front end, which has been broken for

On Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang