labath added a comment.

The biggest feature I see missing here is the ability to run tests remotely. 
Remote debugging is the most important use case for our team, and now we have a 
number of (experimental) bots running the remote test suite. We want to make 
sure we can debug correctly when the host and target have different 
architectures, operating systems, pointer sizes, etc.

Some of the implications of this are:

- we need to be able to fully specify the toolchain used to compile the target 
executables (specifically, we should not assume the host compiler)
- this includes the need to pass funny compiler switches based on the target 
(some android targets can only run `-pie` executables, some cannot run `-pie` 
executables at all).
- the test suite needs to know how to connect to the remote target (mostly it's 
just executing three commands: `platform select XXX`, `platform connect` and 
`platform settings --working-dir YYY`), but it can get a bit more complicated 
in some cases (if we need to install shared libraries along with the main 
executable, if it involves the test executable writing something to a file, 
- we need to be careful about strong cmake integration. The same lldb binary is 
capable of debugging all kinds of targets. We should not require a fresh cmake 
build to run the test suite against multiple targets. If we need to switch 
similar) and it does not trigger a rebuild then it's usable, but slightly 
inpractical. For us, it would be best to be able a fire off a remote test with 
a single command (like we can do now).

I am not against this going in without the remote feature in the first version, 
but I think we should think hardly about it, as I think it could impact a 
number of design decisions.

Comment at: lit/Expr/TestCallStdStringFunction.test:4
@@ +3,3 @@
+# XFAIL: compiler-icc
+# ->
I don't think anyone has tested lldb with icc in the past few years. We can 
avoid adding those xfails to the new tests.

lldb-commits mailing list

Reply via email to