Support interactive gdb for running individual tests

[htuch]

Today, --run_under=gdb doesn't allow interactivity, as there is no stdin. It's possible to make a remote GDB flow with --run_under=gdbserver work, but it's a pain and requires wrapping to make presentable to developers who are familiar with a gdb <my test binary> kind of flow.

I managed to make this work for the Envoy project in envoyproxy/envoy#749, but this is a bit of a hack - I get --run_under to point to a script that scrapes out the environment and then generates another script to invokes the test binary and gdb with.

There should probably be a cleaner way to do this directly from Bazel.

CC envoyproxy/envoy#415

[aehlig]

Thanks for reporting and I'm glad you found a solution. I see the need for a feature like this, and one way to implement it might be to add a similar wrapping to to bazel's standard skylark library.

[lberki]

What we'll do is to make it so that if you do bazel run <test target>, you'd get an actual interactive shell done by exec()ing the test from the client.

This will also obviate the need for the blaze-run.sh that does the same and that we haven't open sourced for reasons of shame. A long-standing bug to be solved!

[lberki]

/cc @laszlocsomor -- I'm not planning to implement this for Windows and replace it instead with an "ERROR: not implemented" message

[laszlocsomor]

Acknowledged, thanks for letting me know!

[lberki]

Note to self: make it possible to convey the current directory of the client somehow because that's what one would intuitively expect. This requirement is at odds with using bazel run to run tests because tests expect a specific pwd, so we'll have to come up with something smart.

[htuch]

So, one comment on the bazel run approach. I think that this will get us most of the way there. Where it falls slightly short is it's not a full repeater environment for a bazel test execution, since the cc_test args are not supplied AFAIK to the bazel run invocation. So, I think ideally if we could use whatever mechanism is being built but still get a full fidelity test execution it will be super helpful.

[lberki]

Well, you are 50% right :) I agree that it's not a full fidelity execution and that was one of the disadvantages of the approach I'm taking, but it gets us there much earlier than the 100% solution and it has the advantage of finally fixing a few decada e-old (!) bugs in bazel run.

However, the difference is not the command line arguments. Those will be handled correctly. It's that if I navigated through our layers of abstraction well, you won't get a sandbox with bazel run. Nor a timeout, but I doubt that's productive when debugging anyway.