similar to: [LLVMdev] Writing unit tests for DWARF?

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

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

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

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

On Mar 17, 2011, at 8:44 AM, Renato Golin wrote: >> dwarfdump --verify will do this. > > Is this being used in LLVM tests? This is an idea. It is not used in llvm/test tests. > I had a look at your debug tests in clang and they're similar to what I do here. > > The problem with debug tests is that it doesn't depend only on the > compiler, but on the debugger

On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote: > Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. I tried some dwarfdump on a few examples I had and the comparison with codesourcery's gcc is impossible, the resulting Dwarf is very different. For instance, GCC declares the types at

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

Renato, On Mar 17, 2011, at 2:00 PM, Renato Golin wrote: > On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote: >> Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. > > I tried some dwarfdump on a few examples I had and the comparison with > codesourcery's gcc is

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

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

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

On 17 March 2011 14:56, Devang Patel <dpatel at apple.com> wrote: > In other words, someone is changing target independent code generation and expects llvm regression tests to catch all bugs. If that's true, we don't need any build bots linking and executing and running llvm generated code. Ok, that was a bad example... ;) > Again, you're mistaken.  llvm-gcc and

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

When I make a simple test program and call abort() and use LLDB to debug it, it has address-to-line mapping. If I then delete the .o file and run LLDB again, it loses the address-to-line mapping. So there must be DWARF info, or otherwise address-to-line info in the .o file. I'm parsing the MACH-O executable, which has a LC_SYMTAB entry, and one of the entries is the file path of the .o file.

Hey James, This sounds really interesting. A few things that come to mind: - I'm curious what kind of errors you'd be okay with in dump mode but not in consumer mode. From LLDB's perspective, we probably want to extract as much information as possible from a malformed line table, as long as we don't end up lying of course. - I need to take another look at the code, but

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

Hi all, I'm preparing to propose some additional error checks for the DWARF debug line parser which we have locally. However, there have been some valid comments in the past that some errors really shouldn't prevent parsing for certain situations. For example, a line_range of 0 would only be an issue if anything needed that information (and would consequently divide by zero), whilst the