[GR-71854][Native Image] -march build parameter is ignored

[vggonz]

Describe the Issue

We have to run the output binary in several machines with diferente CPUs, some newer and some older. So we wanted to adapt the compilation to match the ISA level of the target CPU according with the documentation (checked with native-image -march=list. But compiling with the build arg -march is ignored. For example passing -march=x86-64-v2 the output binary still uses the x86-64-baseline ISA.

Using the latest version of GraalVM can resolve many issues.

• I tried with the latest version of GraalVM.

GraalVM Version

java version "25.0.1" 2025-10-21 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 25.0.1+8.1 (build 25.0.1+8-LTS-jvmci-b01)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 25.0.1+8.1 (build 25.0.1+8-LTS-jvmci-b01, mixed mode, sharing)

Operating System and Version

Linux 6.8.0-88-generic #89-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct 11 01:02:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Build Command

Generated by the maven build plugin:

native-image -cp demo/target/classes:/.m2/repository/org/springframework/boot/spring-boot-starter/4.0.0/spring-boot-starter-4.0.0.jar:/.m2/repository/org/springframework/boot/spring-boot-starter-logging/4.0.0/spring-boot-starter-logging-4.0.0.jar:/.m2/repository/ch/qos/logback/logback-classic/1.5.21/logback-classic-1.5.21.jar:/.m2/repository/ch/qos/logback/logback-core/1.5.21/logback-core-1.5.21.jar:/.m2/repository/org/apache/logging/log4j/log4j-to-slf4j/2.25.2/log4j-to-slf4j-2.25.2.jar:/.m2/repository/org/apache/logging/log4j/log4j-api/2.25.2/log4j-api-2.25.2.jar:/.m2/repository/org/slf4j/jul-to-slf4j/2.0.17/jul-to-slf4j-2.0.17.jar:/.m2/repository/org/springframework/boot/spring-boot-autoconfigure/4.0.0/spring-boot-autoconfigure-4.0.0.jar:/.m2/repository/org/springframework/boot/spring-boot/4.0.0/spring-boot-4.0.0.jar:/.m2/repository/org/springframework/spring-context/7.0.1/spring-context-7.0.1.jar:/.m2/repository/org/springframework/spring-aop/7.0.1/spring-aop-7.0.1.jar:/.m2/repository/org/springframework/spring-beans/7.0.1/spring-beans-7.0.1.jar:/.m2/repository/org/springframework/spring-expression/7.0.1/spring-expression-7.0.1.jar:/.m2/repository/io/micrometer/micrometer-observation/1.16.0/micrometer-observation-1.16.0.jar:/.m2/repository/io/micrometer/micrometer-commons/1.16.0/micrometer-commons-1.16.0.jar:/.m2/repository/jakarta/annotation/jakarta.annotation-api/3.0.0/jakarta.annotation-api-3.0.0.jar:/.m2/repository/org/yaml/snakeyaml/2.5/snakeyaml-2.5.jar:/.m2/repository/org/slf4j/slf4j-api/2.0.17/slf4j-api-2.0.17.jar:/.m2/repository/org/springframework/spring-core/7.0.1/spring-core-7.0.1.jar:/.m2/repository/commons-logging/commons-logging/1.3.5/commons-logging-1.3.5.jar:~/.m2/repository/org/jspecify/jspecify/1.0.0/jspecify-1.0.0.jar --no-fallback -o demo/target/demo -H:ConfigurationFileDirectories=demo/target/graalvm-reachability-metadata/3a8416e1f6953ccf2a599d83df093bbc995602f9/commons-logging/commons-logging/1.2,demo/target/graalvm-reachability-metadata/3a8416e1f6953ccf2a599d83df093bbc995602f9/ch.qos.logback/logback-classic/1.4.9,demo/target/graalvm-reachability-metadata/3a8416e1f6953ccf2a599d83df093bbc995602f9/commons-logging/commons-logging/1.2,demo/target/graalvm-reachability-metadata/3a8416e1f6953ccf2a599d83df093bbc995602f9/ch.qos.logback/logback-classic/1.4.9 -Ob -march=x86-64-v2

Expected Behavior

Checking with readelf -n demo it should output:
Properties: x86 ISA needed: x86-64-v2

Actual Behavior

Checking with readelf -n demo is outputs:
Properties: x86 ISA needed: x86-64-baseline

Steps to Reproduce

1. Build the binary with -march=x86-64-v2
2. Check the file with readelf -n

Additional Context

Repository example: https://github.com/vggonz/graalvm-example
Run with mvn clean package -Pnative

Build Log Output and Error Messages

Java version: 25.0.1+8-LTS, vendor version: Oracle GraalVM 25.0.1+8.1
Graal compiler: optimization level: b, target machine: x86-64-v2, PGO: off
C compiler: gcc (linux, x86_64, 13.3.0)
Garbage collector: Serial GC (max heap size: 80% of RAM)
2 user-specific feature(s):

• com.oracle.svm.thirdparty.gson.GsonFeature
• org.springframework.aot.nativex.feature.PreComputeFieldFeature

[wirthi]

Hi,

I am investigating this.

I don't see any impact of other flags on this - whether you provide -O in any variant (s, b, 0, 3, etc.) does not make a difference.

We seem to correctly set CPU features based on the architecture selected via -march.

I currently assume the problem you are observing - that readelf prints a wrong architecture - stems from the fact that we simply don't make the linker aware what architecture we are using in detail and thus the information is not written into the binary. Only the rather high-level x86-64 lands there, and thus ld uses x86-64-baseline to write into the .note.gnu.property.

So, my working hypothesis is: all good and working as expected, but the readelf output is imprecise.

Christian