[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

Jim Ingham via lldb-commits lldb-commits at lists.llvm.org
Fri Jul 21 18:14:53 PDT 2017


Not at present, but you presumably know more about this than I do.  Part of the point of Greg's extracting the DWARF parser from lldb and making it into it's own library in llvm was precisely so that somebody could then write a simple wrapper tool that would poke it with not necessarily complete but interesting canned bits of DWARF and see that it does the right thing.  I thought you were involved with the reviews for that work?  I was not paying attention to the details of that effort as DWARF parsing's not really my thing.

Anyway, the extraction of the DWARF parser was Greg's last act before leaving Apple, and the project stalled at that point.  I don't imagine he could have gotten that code into llvm without some testing, so the kind of test you are thinking of should be done using whatever mechanism you guys devised for the new llvm dwarf parser.  Of course, it's less interesting to test the llvm version of the DWARF parser if lldb's not using it, so for that to be directly relevant here that piece of work would need to be done.

Jim



> On Jul 21, 2017, at 5:51 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <reviews at reviews.llvm.org> wrote:
> clayborg accepted this revision.
> clayborg added a comment.
> 
> Looks like there already is a test case that was failing as Jim mentioned. Accepting based on that.
> 
> Ah, I was thinking more a test that would've failed when LLDB regressed (regardless of whether Clang was still producing this DWARF or not) - does LLDB have tests like that? (either binary, asm, or some other terse way of writing DWARF directly to test "does LLDB do the right thing with this DWARF" sort of tests?)
>  
> 
> 
> https://reviews.llvm.org/D35740
> 
> 
> 



More information about the lldb-commits mailing list