[Lldb-commits] [PATCH] D76470: [lldb/Target] Rework the way the inferior environment is created

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Mar 20 11:55:32 PDT 2020


jingham added a comment.

In D76470#1934146 <https://reviews.llvm.org/D76470#1934146>, @friss wrote:

> In D76470#1933910 <https://reviews.llvm.org/D76470#1933910>, @jingham wrote:
>
> > Is there any command-based way to see the entire environment that a process will get when it launches?  By populating target.env-vars with the inherited environment there was a way to mostly do that, but I don't see that anymore.  It seems a shame not to be able to see that...
>
>
> No, there is no way to do this, but it's not really a regression. If you do  `settings show target.env-vars` today before running then you won't see what is going to be passed. Only after the first run will it be populated. This was a surprise to me and I find it highly inconsistent. Maybe I can add another property that would get updated with the computed environment. Do we have anything like read-only properties?


No, but I don't think I'd do this with a property anyway.  You are asking the target to compute the result of the various settings that affect the environment of a process it might launch.  That sounds more like the result of a command ("target show-environment" or something like that.)  If we knew how to get the environment from a running process, the same command could show the current environment in a running process, which would sometimes be handy.

I agree the behavior before was pretty unhelpful, so I don't think you need to add a new command to access this in this change set.  But we should put it on our list of things to do.

> 
> 
>> Also, it does seem weird to me that unset-env-vars would override setting a target.env-var explicitly.  What I'm likely to do is say: environment variable 'PUT_HERE_TO_ANNOY_JIM' is always getting set, and I don't want it to be when I'm debugging, so I put:
>> 
>> settings set target.unset-env-vars PUT_HERE_TO_ANNOY_JIM
>> 
>> in my .lldbinit and then after a couple month of debugging happiness, I forget that I put it there.
>> 
>> Then for some reason in a debugging session I want to set it.  So I do:
>> 
>> (lldb) env PUT_HERE_TO_ANNOY_JIM="Okay, This One Time..."
>> 
>> But then when I run my process, it doesn't get set.  Now I have to go back and remember that I had done the unset thing...
>> 
>> It really seems to me the automatic unsets should happen before the explicit sets.  And given the only way you get anything before the automatic sets is the inherited environment, it doesn't make sense to me to apply the unsets if inherit is off.
> 
> This is pretty far-fetched to me, but I also don't really care. I'm fine with having `env-vars` override `unset-env-vars`.

If a variable FOO exists in lldb's environment with the value BAR, and then I have done `env FOO=BAZ`, when the process launches, FOO will be BAZ, not BAR.  So it would be inconsistent to have env-vars override the values of lldb environment variables, but not the entries in unset-env-vars.  So I do think that way makes more sense.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76470/new/

https://reviews.llvm.org/D76470





More information about the lldb-commits mailing list