> On Dec 2, 2019, at 4:08 PM, Vadim Chugunov <vadi...@gmail.com> wrote:
>
> > But I don't think passing lldb's environment variables automatically when
> > running a remote process is a sensible thing to do - certainly not as the
> > default anyway. If the host and target are different OS'es and maybe
> > different users, etc. lldb's environment may very well not be appropriate
> > for the target process.
>
> That's what I'm saying - I could not figure out how to correctly launch a
> remote application via SB API (other than executing "process launch" via
> command interpreter, I suppose).
>
> > Sounds like there should also be an lldb.eLaunchFlagInheritEnv that
> > triggers the same behavior from the SB API.
>
> So it's a bug then?
At least a missing feature. When debugging a process on a remote system, I'm
not sure lldb knows what the entries and their values should be in the default
environment. Using its own environment doesn't make much sense. Things like
HOME and CWD are unlikely to make sense, and even USER could very well be wrong
on the remote system. The only reasonable thing to do is for lldb to tell
debugserver or lldbserver to use their environment - since either one of those
was launched by the remote user on that system, and so are probably a good
starting point. The simplest way to do that is just to have a flag to do
"target.inherit-env" or not, and let lldbserver/debugserver handle that. In
the API's where you are passing a SBLaunchInfo, we really want the contents of
the LaunchInfo to control the launch process without hidden defaults
complicating matters. So if you wanted to start with some useful environment
on a remote target, adding a flag to SBLaunchInfo and getting that to work like
"target.inherit-env" seems like a good way to go.
Jim
>
>
> On Mon, Dec 2, 2019 at 2:59 PM Jim Ingham <jing...@apple.com> wrote:
> There's a setting (target.inherit-env) that controls whether "process launch"
> passes its environment variables along with any newly set to the process in
> question. Sounds like there should also be an lldb.eLaunchFlagInheritEnv
> that triggers the same behavior from the SB API.
>
> But I don't think passing lldb's environment variables automatically when
> running a remote process is a sensible thing to do - certainly not as the
> default anyway. If the host and target are different OS'es and maybe
> different users, etc. lldb's environment may very well not be appropriate for
> the target process.
>
> JIm
>
>
> > On Nov 26, 2019, at 6:13 PM, Vadim Chugunov via lldb-dev
> > <lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> > I am trying to figure out the proper way of using LLDB's SBLaunchInfo class:
> > When I launch a process via CLI interpreter, it seems to receive all of the
> > environment variables inherited from shell, plus the ones I set via
> > `target.env-vars`:
> >
> > (lldb) file /usr/bin/env
> > Current executable set to '/usr/bin/env' (x86_64).
> > (lldb) set set target.env-vars 'FOO=BAR'
> > (lldb) run
> > Process 12733 launched: '/usr/bin/env' (x86_64)
> > FOO=BAR
> > GDM_LANG=en_US
> > CINNAMON_SOFTWARE_RENDERING=1
> > MUFFIN_NO_SHADOWS=1
> > <the rest of my environment variables>
> > Process 12733 exited with status = 0 (0x00000000)
> >
> > But when I launch via SB API, it looks like only the values explicitly
> > added to launch_info are passed to the debuggee:
> >
> > (lldb) script from lldb import *
> > (lldb) script t = lldb.debugger.CreateTarget('/usr/bin/env')
> > (lldb) script li = SBLaunchInfo([])
> > (lldb) script li.SetEnvironmentEntries(['FOO=BAR'], True)
> > (lldb) script t.Launch(li, SBError())
> > <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at
> > 0x7fbc674ea0f0> >
> > FOO=BAR
> > Process 13331 exited with status = 0 (0x00000000)
> >
> > Is this how it's supposed to work? If so, I can certainly add all
> > inherited env vars to launch_info myself, but it isn't clear what to do in
> > the case of remote debugging, because I couldn't find any way of retrieving
> > environment from the remote machine.
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
