[GR-71544] Expand JDWP configuration options

[Berstanio]

Feature request

Please include the following information:

Is your feature request related to a problem? Please describe.
I'm using native-image/svm to deploy to java applications to iOS. This works fine in most parts, but when trying to port the new JDWP option, I encountered a few configuration issues:

• iOS needs to bundle extra dynamic libraries in "frameworks". This will look like: <my-app>.app/Frameworks/svmjdwp.framework/svmjdwp in the final bundle. However, in the current code

  graal/substratevm/src/com.oracle.svm.jdwp.resident/src/com/oracle/svm/jdwp/resident/DebuggingOnDemandHandler.java

  Lines 481 to 486 in f44455b

  	libraryName = System.mapLibraryName("svmjdwp");
  	searchPaths = filterValidPaths(
  	libraryPath,
  	Path.of(ProcessProperties.getExecutableName()).getParent(),
  	librariesInJavaHome(libraryPath),
  	librariesInJavaHome(findJavaHome()));

  , this can't be configured properly, as System#mapLibraryName returns a .dylib ending.
• The metadata file lookup is hardcoded to lookup the file by a very specific naming pattern:

  graal/substratevm/src/com.oracle.svm.interpreter.metadata/src/com/oracle/svm/interpreter/metadata/MetadataUtil.java

  Lines 154 to 158 in f44455b

  	public static String metadataFileName(String binaryFileName) {
  	assert !binaryFileName.isEmpty();
  	assert !binaryFileName.endsWith(File.pathSeparator);
  	return binaryFileName + METADATA_SUFFIX;
  	}

  . This is difficult for iOS, as the name the native-image was build for doesn't need to correlate to the final app name at all. Furthermore, it doesn't allows to bundle multiple metadata files in one app bundle, since app bundles support multiple architectures at once.

Describe the solution you'd like.
It would be great to have the following options:

• Pass a metadata path as a JDWP option that is accepted without further filename validation
• Have a way to pass the svmjdwp binary path as a JDWP, which bypasses file name validation (currently, it will check that the passed file name matches the expected one)

Alternativly, for issue 1., support for iOS could generally be extended with something like this:

diff --git a/substratevm/src/com.oracle.svm.jdwp.resident/src/com/oracle/svm/jdwp/resident/DebuggingOnDemandHandler.java b/substratevm/src/com.oracle.svm.jdwp.resident/src/com/oracle/svm/jdwp/resident/DebuggingOnDemandHandler.java
--- a/substratevm/src/com.oracle.svm.jdwp.resident/src/com/oracle/svm/jdwp/resident/DebuggingOnDemandHandler.java	(revision 20c47fe3f0f525b15e4c00f801ee50232cb5ad8e)
+++ b/substratevm/src/com.oracle.svm.jdwp.resident/src/com/oracle/svm/jdwp/resident/DebuggingOnDemandHandler.java	(date 1763381704100)
@@ -32,6 +32,8 @@
 import org.graalvm.nativeimage.CurrentIsolate;
 import org.graalvm.nativeimage.Isolate;
 import org.graalvm.nativeimage.IsolateThread;
+import org.graalvm.nativeimage.Platform;
+import org.graalvm.nativeimage.Platforms;
 import org.graalvm.nativeimage.ProcessProperties;
 import org.graalvm.nativeimage.StackValue;
 import org.graalvm.nativeimage.c.function.CEntryPoint;
@@ -479,12 +481,22 @@
                             jvmLibraryInJavaHome(findJavaHome()));
         } else {
             assert "native".equals(jdwpOptions.mode());
-            libraryName = System.mapLibraryName("svmjdwp");
-            searchPaths = filterValidPaths(
-                            libraryPath,
-                            Path.of(ProcessProperties.getExecutableName()).getParent(),
-                            librariesInJavaHome(libraryPath),
-                            librariesInJavaHome(findJavaHome()));
+            if (Platform.includedIn(Platform.IOS.class)) {
+                libraryName = "svmjdwp";
+                searchPaths = filterValidPaths(
+                        libraryPath,
+                        Path.of(ProcessProperties.getExecutableName()).getParent(),
+                        Path.of(ProcessProperties.getExecutableName()).getParent().resolve("Frameworks").resolve("svmjdwp.framework"),
+                        librariesInJavaHome(libraryPath),
+                        librariesInJavaHome(findJavaHome()));
+            } else {
+                libraryName = System.mapLibraryName("svmjdwp");
+                searchPaths = filterValidPaths(
+                        libraryPath,
+                        Path.of(ProcessProperties.getExecutableName()).getParent(),
+                        librariesInJavaHome(libraryPath),
+                        librariesInJavaHome(findJavaHome()));
+            }
         }
 
         return findLibrary(libraryName, true, searchPaths);

But just letting users pass an absolute svmjdwp path would be plenty fine.

Describe who do you think will benefit the most.
GraalVM users and GraalVM library developers, who want to enable JDWP support on iOS, without building graal from source.

Describe alternatives you've considered.
Building graalvm from source and/or patching System#mapLibraryName. However, both don't work for the metadata path issue.
I would also not like patching System#mapLibraryName, as some of my users might rely on this behaviour.
I also considered applying substitutes, which works fine, but I think having an inbuild option is way more convinient.

Additional context.
The feature request is for this repository: https://github.com/multi-os-engine/multi-os-engine/tree/moe-svm
I'm in the process to discontinue the old ART based AOT compiler backend, and switch to native-image.

Express whether you'd like to help contributing this feature
I can contribute a change, however I think the main issue is rather how to fix this, not the time it takes to do so.

[gilles-duboscq]

I think letting users pass the full path to svmjdwp as a JDWP option to be parsed in com.oracle.svm.jdwp.bridge.DebugOptions#parse sounds good.

Regarding the path to the metadata file i also agree that adding an option to specify the path relative to the executable makes sense. This can probably be a RuntimeOptionKey.

What do you think @lewurm?

I can contribute a change, however I think the main issue is rather how to fix this, not the time it takes to do so.

Contributions would be greatly appreciated!