DavidSpickett wrote: > I don't know what tools exist.
Seems to be broadly at two levels. First is using the actual network interfaces such as in https://developers.redhat.com/articles/2025/05/26/how-simulate-network-latency-local-containers. This is a bit scary and only works for Linux. The second is a TCP proxy like https://github.com/shopify/toxiproxy#1-installing-toxiproxy. First time I've tried something like it but it was really easy to use in between `lldb` and `lldb-server`. ``` $ ./toxiproxy-server & $ ./toxiproxy-cli create --listen 127.0.0.1:1234 --upstream 127.0.0.1:1235 slow-server $ ./toxiproxy-cli toxic add --type latency --attribute latency=1000 slow-server $ ./toxiproxy-cli inspect slow-server Name: slow-server Listen: 127.0.0.1:1234 Upstream: 127.0.0.1:1235 ====================================================================== Upstream toxics: Proxy has no Upstream toxics enabled. Downstream toxics: latency_downstream: type=latency stream=downstream toxicity=1.00 attributes=[ jitter=0latency=1000 ] ``` There are other "toxics" https://github.com/Shopify/toxiproxy/tree/main/toxics you can enable. Now connect lldb to the downstream and lldb-server to the upstream: ``` $ ./bin/lldb-server gdbserver localhost:1235 -- /tmp/test.o $ time ~/build-llvm-aarch64/bin/lldb /tmp/test.o -b -o "gdb-remote 1234" -o "b main" -o "run" <...> real 0m30.363s user 0m0.293s sys 0m0.097s ``` Normally this takes 0.366 seconds. We can further prove it works by exceeding the usual packet timeout: ``` $ ./toxiproxy-cli toxic remove --toxicName latency_downstream slow-server $ ./toxiproxy-cli toxic add --type latency --attribute latency=10000 slow-server (lldb) gdb-remote 1234 error: failed to get reply to handshake packet within timeout of 6.0 seconds <...> real 0m6.113s ``` Some drawbacks to this: * You have to be able to install this application. Practically (is it possible to access the machines), policy (are you allowed to install software that's not vetted) and human (why are you making me install random software) concerns. * You can run the lldb test suite by pretending it's a remote (https://lldb.llvm.org/resources/test.html#running-the-test-suite-remotely). However that is more setup than adding the one `settings set ....` command, which is easier to toggle on and off. Good things: * Unmodified lldb, so you can add delay to versions without the setting. You could even delay GDB for comparison purposes, if one is allowed to interact with such things :) * You can delay either side of the connection, though that likely isn't important for this work. This PR's changes are pretty simple and I don't see that anyone will build their entire workflow off of this clearly testing only setting. So if the above concerns are a problem for what you're doing, I don't object to adding an lldb setting for it. https://github.com/llvm/llvm-project/pull/195440 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
