[lldb-dev] RFC: Moving debug info parsing out of process

Adrian Prantl via lldb-dev lldb-dev at lists.llvm.org
Wed Mar 6 13:08:37 PST 2019



> On Mar 6, 2019, at 9:43 AM, Zachary Turner <zturner at google.com> wrote:
> 
> 
> On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote:
> On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> It becomes testable as an independent component, because you can just send requests to it and dump the results and see if they make sense.  Currently there is almost zero test coverage of this aspect of LLDB apart from what you can get after going through many levels of indirection via spinning up a full debug session and doing things that indirectly result in symbol queries.
> 
> You are right that the type system debug info ingestion and AST reconstruction is primarily tested end-to-end.
> Do you consider this something worth addressing by testing the debug info ingestion in isolation?
> 
>  Wanted to bump this thread for visibility.  If nothing else, I'm interested in an answer to this question.  Because if people agree that it would be valuable to test this going forward, we should work out a plan about what such tests would look like and how to refactor the code appropriately to make it possible.

I think it would help me a lot to have a better idea what level of abstraction you are imagining. Could perhaps come up with a mock-up example with some mad-up syntax / API for what such a test could look like? More testing is always desirable, of course, but I'm afraid that we might end up in a situation like we are with yaml2obj, where we can only test really trivial things nicely and all the interesting cases aren't representable at all.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190306/67c9f430/attachment.html>


More information about the lldb-dev mailing list