similar to: [LLVMdev] Accessing Dwarf data at runtime

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

Another chapter in the long saga of trying to get source-level debugging working :) I've switched over to using the direct object-file generation instead of generating assembly in hopes of getting around the "Fatal error: duplicate .debug_line sections" binutils bug. I now have 4 different tools for dumping the DWARF info for an object module: dwarfdump, objdump, readelf, and

On Thu, Nov 25, 2010 at 5:55 PM, Talin <viridia at gmail.com> wrote: > 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 Oct 10, 2010, at 7:21 PM, Talin <viridia at gmail.com> wrote: > On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack

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 Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved > the problem, but because I simply gave up and decided to work on other > things for a while since I was making no progress. Having finished those > other things (the stack crawler, for one), I'm hoping that time and a fresh >

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

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 Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But

>> 1. llvm-dwarfdump: the best approach when it works. But unfortunately >> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections >> like debug_frame aren't supported. >> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >> cumbersome and misses a lot of things like actual DWARF encoding. >> 3. Using elf-dump and examining

On Mon, Oct 11, 2010 at 11:12 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 11, 2010, at 11:04 AM, Talin wrote: > > On Mon, Oct 11, 2010 at 10:43 AM, Chris Lattner <clattner at apple.com>wrote: > >> >> On Oct 11, 2010, at 8:17 AM, Devang Patel wrote: >> >> >> Interestingly enough, I just upgraded to the latest Ubuntu (10.10 -

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

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > 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

+ other debug info people (Eric & Paul) On Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1.

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

Is there/could you further explain the use-case for adding an index to an existing binary? Certainly not the worst idea/could come in handy sometimes, but you mention benchmarking - is the benefit of not recompiling/relinking that significant to such experiments? If it's not for use in a common workflow, but only in a compiler/debugger development workflow, it doesn't seem so important to

On 17 March 2011 06:40, Talin <viridia at gmail.com> wrote: > 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, because if you do make a mistake, the only way you'll find > out is because gdb refuses to debug your program. And as I work on the code, >

>> 1. llvm-dwarfdump: the best approach when it works. But unfortunately >> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections >> like debug_frame aren't supported. > > Ideally I'd like to see support added whenever a code change is made > to a feature - so long as we hold ourselves to a "test new changes" > that can

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: