On 10/03/2026 7:23 pm, Baesken, Matthias wrote:
I'm not sure where this conclusion is coming from. The case in question
was about "debug" but as stated earlier and/or in the JBS issue this is
potentially an issue for any symbol exported from one of the JDK
libraries that clashes with a symbol from the application native code.
Hi David, I think we were running with exported debug-helper functions on
Windows for some years without complains .
And on Linux , there was only this single issue about "debug" . So in practice
it was not THAT bad.
Agreed.
However you are correct, that it *could* clash in some scenarios . (but all
our other exported functions without nice prefix could clash too)
Separate issue that those unprefixed symbols possibly should not (all)
be exported.
So we have at least two option :
- prefix the names from debug.cpp (jvm_debug_ or something like this, maybe
there are better suggestions)
- use an exported "helper" that references all those little functions , so that
elimination is avoided , e.g.
// just an exported helper; to avoid link time elimination of the referenced
functions
extern "C" JNIEXPORT void JVM_debug_helpers_keeper(void* p1, void* p2, void*
p3, intptr_t ip, oop oh, address adr) {
blob((CodeBlob*)p1);
dump_vtable(adr);
nm(ip);
disnm(ip);
printnm(ip);
universe();
verify();
...........
}
This one is not there to be ever called, just for keeping the nm/pp/debug etc.
functions.
What do you think ?
I'm a little confused. Calling the wrong function because of a name
clash seems quite a different problem from linking stripping out
functions it doesn't realize could be used. Are we using the prefixes to
prevent linker stripping?
Would that JVM_debug_helpers_keeper(...) approach also work on Windows ?
No idea - sorry.
David
Best regards, Matthias
