Graal: Native application debug info leaks(?) file paths of release/build machines?

[jaikiran]

Now that native-image (and Quarkus) allows generation of debug info in the native application, I've been fiddling with it to get started. While doing so, I noticed that the debug info seems to leak(?) the filesystem paths of the machine where the Graal VM native-image tool was built and released from? For example, I launch a Quarkus application using gdb and then on the gdb prompt do:

(gdb) info functions

This shows the following output:

All defined functions:

File /Users/graal2/slave/e/main/substratevm/src/com.oracle.svm.native.jvm.posix/src/JvmFuncs.c:
62: int JVM_ActiveProcessorCount();
175:    void JVM_BeforeHalt();
66: int JVM_Connect(int, struct sockaddr *, socklen_t);
143:    jlong JVM_CurrentTimeMillis(void *, void *);
197:    jobject JVM_DoPrivileged(JNIEnv *, jclass, jobject, jobject, jboolean);
70: void *JVM_FindLibraryEntry(void *, const char *);
74: int JVM_GetHostName(char *, int);
178:    int JVM_GetLastErrorString(char *, int);
151:    jlong JVM_GetNanoTimeAdjustment(void *, void *, jlong);
87: int JVM_GetSockName(int, struct sockaddr *, socklen_t *);
78: int JVM_GetSockOpt(int, int, int, char *, socklen_t *);
171:    void JVM_Halt(int);
124:    int JVM_InitializeSocketLibrary();
91: int JVM_Listen(int, int);
147:    jlong JVM_NanoTime(void *, void *);
95: int JVM_Send(int, char *, size_t, uint);
99: int JVM_SetSockOpt(int, int, int, const char *, socklen_t);
83: int JVM_Socket(int, int, int);
104:    int JVM_SocketAvailable(int, int *);
115:    int JVM_SocketClose(int);
119:    int JVM_SocketShutdown(int, int);
129:    jlong Java_java_lang_System_currentTimeMillis(void *, void *);
135:    jlong Java_java_lang_System_nanoTime(void *, void *);
167:    jlong Java_jdk_internal_misc_VM_getNanoTimeAdjustment(void *, void *, jlong);
214:    jobject Java_sun_nio_ch_sctp_SctpChannelImpl_initIDs(JNIEnv *);
224:    jboolean VerifyClassname(char *, jboolean);
219:    jboolean VerifyFixClassname(char *);
257:    int jio_fprintf(FILE *, const char *, ...);
248:    int jio_snprintf(char *, size_t, const char *, ...);
229:    int jio_vfprintf(FILE *, const char *, struct __va_list_tag *);
233:    int jio_vsnprintf(char *, size_t, const char *, struct __va_list_tag *);

File /Users/graal2/slave/e/main/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c:
116:    void determineCPUFeatures(CPUFeatures *);
43: int get_cpuid(unsigned int, unsigned int *, unsigned int *, unsigned int *, unsigned int *);
36: 
    int get_cpuid_count(unsigned int, unsigned int, unsigned int *, unsigned int *, unsigned int *, unsigned int *);

File /Users/graal2/slave/e/main/substratevm/src/com.oracle.svm.native.libchelper/src/cSunMiscSignal.c:
173:    int cSunMiscSignal_await();
152:    int cSunMiscSignal_close();
222:    sig_t cSunMiscSignal_countingHandlerFunctionPointer();
213:    long cSunMiscSignal_decrementCount(const int);
202:    long cSunMiscSignal_getCount(const int);
102:    int cSunMiscSignal_open();
187:    int cSunMiscSignal_post();
197:    int cSunMiscSignal_signalRangeCheck(const int);
235:    static void cSunMiscSignal_countingHandler(int);

Notice the /Users/graal2/slave/e/main/ file paths in there. Is that OK? I haven't debugged any native applications before so I'm unsure if data like this, in the debug info, is considered common and acceptable.

[adinn]

I just want to note that this is debug info added by the C compiler not by GraalVM Native. If it needs fixing (on which question I am agnostic) then that has to be achieved by driving the C compiler or linker appropriately (i.e. this is a build issue not a coding issue).

[olpaw]

@adinn is right. This needs to be fixed in our build system. Specifically the part of mx that deals with native-code compilation.

[olpaw]

Fixed by https://github.com/graalvm/mx/commit/ba0c0bee111142a91496b38c9a5c11ad91f6ba29