This adds the necessary boiler plate to capture and replay API tests.
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Differential D77588
[lldb/Reproducers] Make it possible to capture reproducers for the Python test suite. JDevlieghere on Apr 6 2020, 2:25 PM. Authored by
Details This adds the necessary boiler plate to capture and replay API tests. http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Diff Detail
Event Timeline
Comment Actions I think the code looks ok now, though I have to say I am still somewhat fuzzy on what exactly will this patch enable. I think I understand the capture part, but what happens during replay? Will that already be smart enough to match the SB calls made by the test harness during replay to the captured calls that were made during recording, or is there some more work needed there? Could you add a brief documentation on this somewhere? Comment Actions That's implemented in https://reviews.llvm.org/D77602
Sure thing: https://reviews.llvm.org/D77771 Comment Actions Ok, I'm starting to understand what's going on here. This patch looks mostly fine, but IIUC, it won't really do anything until the subsequent patch lands as that is what implements the inline/api/passive replay. I'm going to start looking at that other patch now. Comment Actions It's sufficient for stage one, i.e. capture the test suite and use the driver (active replay), but it also contains the necessary changes for stage 2 (passive replay). I could've split it up in two patches but given that the changes are so similar that didn't seem worth it. |
I am doubly unhappy about this. Not only does it leak testing logic into production code, it actually does that using environment variables... :/
I take it the problem here is that reproducers need to be set up before the Initialize call, but the lldb module does not let us do that as it calls Initialize automatically? I am not sure that was such a wise idea, but that ship has sailed a long time ago.
So, can we at least do something like this instead? I.e. have a separate configuration module which would be imported here and would drive this logic.
I believe it should be possible to arrange it so that the configuration module does not even have to get shipped -- this code could just attempt the import and ignore any errors.
And the configuration module itself would not need to do anything reproducer-related either. It could just contain a single flag to disable the automatic initialization. That sounds like a thing someone might conceivably want anyway, and it could be later extended to handle other kinds of global lldb configuration (ConstString pool size maybe ?).
Once the Initialize call is disabled, the normal test harness can handle the rest...