labath added a comment. In https://reviews.llvm.org/D41352#959051, @jasonmolenda wrote:
> I guess I don't have an opinion on this one. The correct way to pass > environment variables to the inferior is through > SBLaunchInfo::SetEnvironmentEntries or in cmd line lldb, process launch -v > ENV=val. A test that assumes an environment variable set in lldb will end up > in the inferior process isn't going to work when the process is launched on a > remote target, is it? First a bit of background: We have an internal customer who uses `lldb-server ... -- ./my_app --my_app_arguments` + `process connect ...` combo for their debugging setup (mainly because this is compatible with their existing gdb setup). However, their app was failing to run because it was expecting some environment variables to be set, and lldb-server was launching it with a clean environment. In this setup, it is not possible to set the environment variables via SBLaunchInfo, as lldb (client) is not responsible for launching the inferior -- as far as the client goes this situation is most similar to an "attach". > Whether llgs or debugserver should be forwarding their environment variables > on by default - it seems fragile to me. But maybe there's a use case that > needs this behavior to be supported? I guess it's valid to test that it > actually behaves that way, at least for processes launched on the local > system. Note that I am only suggesting to pass the environment in the "pre-loaded inferior" mode (I'm not sure if it has an official name). I agree that the (regular) case where the inferior is launched under the control of the client via $A packets should remain the same, as in this case the client is able to setup the environment exactly as it wants to. However, in the pre-loaded mode we have just two options: launch with the environment inherited from the lldb-server and launch with an empty environment. Of these, I think the first one is much more useful. The test we are speaking about is also only testing that the environment passing works in the pre-loaded mode. (Right now this test cannot be run remotely, but that's a separate issue which I plan to address in the future.) > (I apologize for not keeping up with lldb-commits the past week while this > was work was being done -- I'm in the middle of a task where I've had to > concentrate on that & pause reading emails etc for a bit. ;) No worries, I am not in a rush with this. https://reviews.llvm.org/D41352 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
