This is an archive of the discontinued LLVM Phabricator instance.

[Reproducers] Change how reproducers are initialized.
ClosedPublic

Authored by JDevlieghere on Nov 28 2018, 5:08 PM.

Details

Summary

This patch changes the way the reproducer is initialized. Rather than making changes at run time we now do everything at initialization time. To make this happen we had to introduce initializer options and their SB variant. This allows us to tell the initializer that we're running in reproducer capture/replay mode.

Because of this change we also had to alter our testing strategy. We cannot reinitialize LLDB when using the dotest infrastructure. Instead we use lit and invoke two instances of the driver.

Another consequence is that we can no longer enable capture or replay through commands. This was bound to go away form the beginning, but I had something in mind where you could enable/disable specific providers. However this seems like it adds very little value right now so I just removed the corresponding commands. This also means you now have to control this through the driver, for which I replaced --reproducer with --capture and --replay.

Diff Detail

Repository
rL LLVM

Event Timeline

JDevlieghere created this revision.Nov 28 2018, 5:08 PM

I have a lot of comments, but I think they're mostly cosmetic. I think the general idea here is good.

include/lldb/API/SBInitializerOptions.h
15 ↗(On Diff #175792)

You cannot include non-API headers from SB headers (cpp files are fine). SystemInitializer::Options needs to forward-declared. (I guess that means moving it out of the SystemInitializer class).

17 ↗(On Diff #175792)

not needed?

32 ↗(On Diff #175792)

I think this will make the copy-constructor of this class deleted, which will not play well with python. I think you'll need to declare your own copy operations here (something like SBExpressionOptions, I guess).

Also, why is this mutable? SBExpressionOptions seems to have that too, but it's not clear to me why would that be needed?

include/lldb/Initialization/SystemInitializer.h
28 ↗(On Diff #175792)

const Options & ? (it contains a string so it's not trivial to copy).

lit/Reproducer/TestGDBRemoteRepro.test
7 ↗(On Diff #175792)

With --target this test will not run on other platforms. This sounds like it should work on platforms using gdb-remote (i.e., mac & linux). Maybe remove the --target and set an appropriate REQUIRES directive.

8 ↗(On Diff #175792)

s/REPLAY/CAPTURE ?

scripts/interface/SBInitializerOptions.i
15 ↗(On Diff #175792)

Weird formatting.

source/Initialization/SystemInitializerCommon.cpp
74 ↗(On Diff #175792)

remove .c_str()

source/Utility/Reproducer.cpp
41–42 ↗(On Diff #175792)

It should be possible to bubble this all the way up to the SBDebugger::Initialize call. Is there a reason to not do that?

tools/driver/CMakeLists.txt
21 ↗(On Diff #175792)

This is wrong. The driver should only use the public API exposed via liblldb. Why did you need to do that?

unittests/Utility/ReproducerTest.cpp
39–43 ↗(On Diff #175792)

You should be able to change the visibility of these via using directives. (using Reproducer::SetCapture).

JDevlieghere marked 12 inline comments as done.

Address feedback from Pavel.

source/Utility/Reproducer.cpp
41–42 ↗(On Diff #175792)

Do you mean having the private Initialize function return an error (and an SBError for the SB variant)?

tools/driver/CMakeLists.txt
21 ↗(On Diff #175792)

I don't remember, anyway it's definitely not necessary or correct.

Test didn't run. Is there a way to REQUIRE either darwin or linux?

Test didn't run. Is there a way to REQUIRE either darwin or linux?

I think the canonical way to do that would be to define a new feature in lit, which gets set when the target supports remote debugging and then use that feature in the REQUIRES directive.

source/Utility/Reproducer.cpp
41–42 ↗(On Diff #175792)

Yes, that's what I meant. Up until now, our initialization functions were mostly just hooking up various pointers, which are things that can't (shouldn't) fail, but if now a simple typo in the reproducer path can cause the initialization to fail, then I think it would be good to report that.

JDevlieghere marked an inline comment as done.

Make initialize return an error.

Test didn't run. Is there a way to REQUIRE either darwin or linux?

I think the canonical way to do that would be to define a new feature in lit, which gets set when the target supports remote debugging and then use that feature in the REQUIRES directive.

I've changed the check to non-windows (as it wouldn't compile there anyway). Is there anything not covered by this that would warrant this new feature?

labath accepted this revision.Dec 3 2018, 1:23 AM

I think the canonical way to do that would be to define a new feature in lit, which gets set when the target supports remote debugging and then use that feature in the REQUIRES directive.

I've changed the check to non-windows (as it wouldn't compile there anyway). Is there anything not covered by this that would warrant this new feature?

Well.. FreeBSD also uses a local debugging plugin, though I don't believe anyone runs tests there on a regular basis. I suppose that could be handled by adding system-freebsd into the UNSUPPORTED clause...

Looks good to me, modulo one comment.

source/Initialization/SystemLifetimeManager.cpp
27 ↗(On Diff #176161)

The calls to this function in lldb-server and lldb-test need to be updated to handle the newly returned Error object.

This revision is now accepted and ready to land.Dec 3 2018, 1:23 AM
This revision was automatically updated to reflect the committed changes.

Thanks, I've disabled the test in r348186 while I try to figure out why it fails.

lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test