Add wrappers for gdb and lldb when invoked from bazel

[ohodson]

Usage:

$ bazel run --run_under $(realpath tools/bazel-gdb-wrapper.sh) //src/workerd/server:workerd --
serve $(realpath /samples/helloworld_esm/config.capnp)

[jp4a50]

Is this perhaps worth a mention in the README, perhaps under "Running workerd"?

[jp4a50]

Is this perhaps worth a mention in the README, perhaps under "Running workerd"?

While we're at it it might be worth encouraging users to set up a bazel --disk_cache to avoid these commands overwriting previous build outputs (and vice versa) due to the extra build options.

[jp4a50]

This comment suggests to me that the features flag alone is sufficient and we should be able to at least do away with the local spawn_strategy?

[ohodson]

Interesting, I cannot tell you how much time I wasted with this OSX only issue, it does indeed appear redundant.

[ohodson]

Is this perhaps worth a mention in the README, perhaps under "Running workerd"?

While we're at it it might be worth encouraging users to set up a bazel --disk_cache to avoid these commands overwriting previous build outputs (and vice versa) due to the extra build options.

Perhaps better in a separate CL and/or separate tips.md under docs/. My workflow uses --remote_cache without --disk_cache. Remote cache is painless and fast enough in practice (https://github.com/buchgr/bazel-remote). I recall Bazel's disk cache being in need of regular maintenance to keep the size in check (a cron-job or a helper-script).

[ohodson]

I've decided to drop this. The changes are fairly trivial and actually don't work for debugging tests, bazel runs tests with a wrapper around your wrapper if you invoke (on an OS-X box):

 bazel run -c dbg --spawn_strategy=local --features=oso_prefix_is_pwd --run_under /Volumes/Source/workerd/tools/bazel-lldb-wrapper.sh //src/workerd/jsg:promise-test

Bazel runs:

 bash external/bazel_tools/tools/test/test-setup.sh /Volumes/Source/workerd/tools/bazel-lldb-wrapper.sh src/workerd/jsg/promise-test

And the bazel test-setup.sh redirects all stdio streams so you can't enter commands into the debugger.

For binaries, there is no equivalent wrapper on the bazel side so debugging binaries work. The main binary here is workerd and we have support for debugging that from vscode which is much more convenient than gdb / lldb at the command-line.