[Native Image] access to location of native image like $0

[hohwille]

Feature request

In my code, I need to determine the installation location where the native binary is located (e.g. to find a configuration via relative path from there).
In every script (like in bash) I do have $0 and $(dirname "$0") (in MSDOS/CMD there is %~dp0).
In Java, I can use System.getProperty("user.dir") but that only gives me $PWD.

I can run:

$ ./my-native-image
$ cd ..
$ ./bin/my-native-image
$ cd /tmp
$ /usr/local/foo/bin/my-native-image

In any of these cases, I would like to find the installation directory where the native image is located (in the example /usr/local/foo/bin/ but could also be C:\foo\bin or whatever).

Is your feature request related to a problem? Please describe.

I need to find this installation directory mentioned above and cannot find any way how to determine it from my Java code.

Describe the solution you'd like.
I would like to access something like $0 from Java-Code.
Ideally a standard Java API could be used like System.getProperty("graalvm.native-image.path") (property name is just an example) and if I am inside a GraalVm native image that property could point to the command with its potential path the user called the native-image (aka $0).
An alternative might be to support getClass().getProtectionDomain().getCodeSource().getLocation() in GraalVM to point to the absolute location of the native-image.

In case I am missing something and there is already a possibility to archive what I want, then just let me know and close the issue.

Describe who do you think will benefit the most.
Developers of native-images having the same need.

Describe alternatives you've considered.
The only workaround, I could think of is providing a wrapper script (in bash and CMD) that determines the installation directory and pass it as an explicit argument to the native image but then using the native image directly would not make much sense for end-users and the workaround feels kind of wrong and stupid.

Additional context.
Maybe I am missing something since Quarkus and Spring-Boot Native must have the same problem and do not require such wrapper script but I cannot find how they might have solved the problem even when digging in their code.

Express whether you'd like to help contributing this feature
I am an OSS developer and would not might contributing but IMHO already understanding where to get started might be more complicated than to apply the actual fix. So I would wait for a first response until further considerations about this.