[GR-33359] Fix image name argument parsing when combined with -m option

[ivan-ristovic]

Summary

This PR adresses two problems related to native-image argument handling. Namely, it:

• fixes NullPointerException in cases when a class could not be found on the provided module path
• modifies argument handling so that when image name is combined with --module argument, the image name is not mistakenly interpreted as a class name

Details

Main class resolving

Currently, our main class resolving is done via:

graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/NativeImageGeneratorRunner.java

Line 340 in 8d70605

mainClass = classLoader.forName(className, mainModule);

There is a catch block present for ClassNotFoundException, however, looking at the call chain, it is possible that control will reach java.lang.Class.forName(Module, String), and by looking at the documentation for this method the return value could be null - which is currently not covered. Therefore, the following line will produce a NullPointerException:

graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/NativeImageGeneratorRunner.java

Line 351 in 8d70605

mainEntryPoint = mainClass.getDeclaredMethod(mainEntryPointName, int.class, CCharPointerPointer.class);

Image name handling in the presence of --module option

Invoking native-image with the following arguments

$ native-image MyClass foo

will produce a binary with the name foo. However, combining this with the --module (-m for short) option, for example

$ native-image -m my.module/MyClass foo

will cause a NullPointerException in the same line as mentioned above. This is tied to class resolving which could return null, however it is a misinterpreted main class argument when -m option is present - the image name will be interpreted as an overrule for the class name.

Implementation details

This PR solves this problem by reusing the same overrule exclusion code used when -jar option is present:

graal/substratevm/src/com.oracle.svm.driver/src/com/oracle/svm/driver/NativeImage.java

Line 1168 in 8d70605

if (!jarOptionMode) {

As for main class resolving, a check is added to ensure that the mainClass field is not null before proceeding onto entry method lookup.

[olpaw]

@ivan-ristovic unfortunately these changes break

    def native_image_func(args, **kwargs):
        all_args = base_args + common_args + args
        path = query_native_image(all_args, r'^-H:Path(@[^=]*)?=')
        name = query_native_image(all_args, r'^-H:Name(@[^=]*)?=') <<< THIS
        image = join(path, name)
        _native_image(all_args, **kwargs)
        return image

in substratevm/mx.substratevm/mx_substratevm.py in the context of

        built_image = native_image([
            '--verbose', '-H:Path=' + build_dir,
            '--trace-class-initialization=hello.lib.Greeter', # also test native-image-diagnostics-agent
            ] + moduletest_run_args)

in mx_substratevm.hellomodule.

There is no -H:Name=... argument emitted by the driver and so mx cannot determine the full path to the image that is going to be created anymore.

[olpaw]

The reason is that now

                            if (hasMainClassModule) {
                                imageBuilderArgs.add(oH(SubstrateOptions.Name, "image-name from module-name") + mainClassModule.toLowerCase());
                            } 

is not used anymore.

[olpaw]

See comments

[ivan-ristovic]

@olpaw Yes, I realise now that in fact we wish to do the same as before, just skip overruling - I moved the check, I think it should be fine now.

[olpaw]

Rerunning in internal CI now ...

[olpaw]

PR is in merge queue