[Mesa-dev] [PATCH v2 1/4] util: Get program name based on path when possible

[Timothy Arceri]

On 26/9/18 12:02 am, Kazlauskas, Nicholas wrote:
> On 09/24/2018 08:00 PM, Timothy Arceri wrote:
>> On 25/9/18 4:18 am, Nicholas Kazlauskas wrote:
>>> Some programs start with the path and command line arguments in
>>> argv[0] (program_invocation_name). Chromium is an example of
>>> an application using mesa that does this.
>>>
>>> This tries to query the real path for the symbolic link /proc/self/exe
>>> to find the program name instead.
>>>
>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas at amd.com>
>>> ---
>>>   src/util/u_process.c | 16 +++++++++++++++-
>>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/util/u_process.c b/src/util/u_process.c
>>> index 5e5927678d..4cae6f6dee 100644
>>> --- a/src/util/u_process.c
>>> +++ b/src/util/u_process.c
>>> @@ -41,8 +41,22 @@ static const char *
>>>   __getProgramName()
>>>   {
>>>      char * arg = strrchr(program_invocation_name, '/');
>>> -   if (arg)
>>> +   if (arg) {
>>> +      /* This is likely part of a Linux file path.
>>> +       * Try to get the program name without any command line 
>>> arguments. */
>>> +      static char * full_path;
>>> +
>>> +      if (!full_path)
>>> +         full_path = realpath("/proc/self/exe", NULL);
>>> +
>>> +      if (full_path) {
>>> +         char * res = strrchr(full_path, '/');
>>> +         if (res)
>>> +            return res+1;
>>> +      }
>>> +
>>>         return arg+1;
>>> +   }
>>
>> This patch still breaks wine apps. Only some apps end up in the code 
>> path below this code hunk i.e. with windows like paths (seems to be 
>> 32-bit apps). Others have proper unix paths and end up in your code 
>> path above.
>>
>> Apologies for not jumping on this earlier you did say this was where 
>> you were headed. I believe you are going to have to implement 
>> Nicolai's suggestion or some other logic to strip off the extra params 
>> from the string.
>>
>> /usr/lib/chromium/chromium --type=gpu-process --field-trial-handle=...
>>
>> For the above the current logic should give you:
>>
>> chromium --type=gpu-process --field-trial-handle=...
>>
>> Is there a reason you can't just break the string at the space. Do 
>> binary names/paths in program_invocation_name end up with the escape 
>> char? e.g if you rename "chromium" "chrom ium" Do you end up with
>> "chrom\ ium"?
>>
>> If so you can look for a space and if it isn't preceded with '\' you 
>> can truncate it.
>>
>>>      /* If there was no '/' at all we likely have a windows like path 
>>> from
>>>       * a wine application.
>>>
> 
> I saw this working in most of the wine applications I've tested so I'm 
> kind of surprised that architecture matters.

Yeah I'm not sure why. There are other strange behaviors with wine such 
as not being able to use the shortname even though our code matches what 
glib is doing, I tried to debug this but got nowhere which is way we now 
use program_invocation_name instead. Anyway that's off topic.

> 
> I thought of a way that could fix this in every case, though.
> 
> The problem here is that program arguments are added to the end of the 
> invocation path. However, what's common with the real path and the 
> invocation path is that they should both have the same program name. The 
> arguments are added to the end, so the program name should be a prefix.
> 
> So if the arguments are "stripped" off by using the prefix this could 
> work. The realpath for wine programs should always be the wine loader 
> itself and if the realpath isn't the prefix for the invocation path then 
> the invocation path could be used directly. Checking the prefix is as 
> simple as using strncmp too.
> 
> I'll do some more testing on this. If you have some examples that 
> demonstrate the problem behavior those would be nice to know for testing.

I've been testing your patches with No Mans Sky.

> 
> Thanks.
> 
> Nicholas Kazlauskas