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.kazlaus...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
