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

[Kazlauskas, Nicholas]

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.

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.

Thanks.

Nicholas Kazlauskas