<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 23, 2017 at 10:54 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jul 22, 2017, at 2:26 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_585475446654799581Apple-interchange-newline"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?</blockquote><div><br>Yep yep - though not necessarily clear on the bigger picture goals in terms of which components were going where in the long term.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I was not paying attention to the details of that effort as DWARF parsing's not really my thing.<br>
<br>
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. </blockquote><div><br>Adrian - any chance something like the DwarfGenerator stuff in LLVM could be used to test this code?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br></blockquote><div><br>Perhaps - or reusing the same testing approach without that. Though I think this particular failure/fix was in a higher/lower different layer than the pure parsing stuff in LLVM, but I could be wrong - there's sufficient divergence it's not obvious from a few class names, etc, to tell how much overlap (& where) there is.<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Yes, I would also say that this is one level above the pure parsing. This is how LLDB interprets the data. Once the LLVM DWARF parser (which is architected more for testability) is complete enough to be used inside LLDB, there is no reason to not also implement this level (cross-referencing dwarf+dwo) inside LLVM and properly test with a unit test or a yaml object description.</div></div></div></blockquote><div><br>Any reason this would need to wait until it's sunk into LLVM? It seems like this kind of testing would be useful to do in LLDB no matter how many libraries are sunk into LLVM - how far off/much work will it be to have this sort of testing available in LLDB?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div> Inside LLDB an end-to-end test like the existing one is as good as it gets now.</div></div></div><div style="word-wrap:break-word"><div><div><br></div>-- adrian</div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jim<br>
<br>
<br>
<br>
> On Jul 21, 2017, at 5:51 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br>
> clayborg accepted this revision.<br>
> clayborg added a comment.<br>
><br>
> Looks like there already is a test case that was failing as Jim mentioned. Accepting based on that.<br>
><br>
> 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?)<br>
><br>
><br>
><br>
> <a href="https://reviews.llvm.org/D35740" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35740</a><br>
><br>
><br>
><br>
<br>
</blockquote></div></div>
</div></blockquote></div></div></blockquote></div></div>