jni gcc mangled names  
Author Message
Remi Arntzen





PostPosted: 2006-10-6 2:14:00 Top

java-programmer, jni gcc mangled names //Crapo.java
public class Crapo {
static {
System.loadLibrary("Crapo");
}
native public static int magicNumber(int n);
public static void main(String... args) {
System.out.println(magicNumber(246));
}
}
//Crapo.c
typedef long long __int64;//gcc doesn't recognize __int64
#include "Crapo.h"
/*
* Class: Crapo
* Method: magicNumber
* Signature: (I)I
*/
JNIEXPORT jint JNICALL Java_Crapo_magicNumber(JNIEnv * env, jclass c,
jint n) {
return 47;
}
//run gcc -mno-cygwin -Wl,--add-stdcall-alias -shared -o Crapo.dll -I
"C:\Program Files\Java\jdk1.6.0\include" -I "C:\Program
Files\Java\jdk1.6.0\include\win32" Crapo.c
//output of nm Crapo.dll
10003040 b .bss
10003020 b .bss
10003000 b .bss
//............ 30+ lines of this crap
1000505c i .idata$5
//..........................
100011d0 T _DllMain@12
10001000 T _DllMainCRTStartup@12
100011c0 T _Java_Crapo_magicNumber@12//<-----------------
10001360 T __CTOR_LIST__
10001368 T __DTOR_LIST__
U __RUNTIME_PSEUDO_RELOC_LIST_END__
U __RUNTIME_PSEUDO_RELOC_LIST__
//................... more crap; to me at least

//it was my understanding that --add-stdcall-alias when passed to the
linker should remove the @12 of _Java_Crapo_magicNumber@12
//run gcc -mno-cygwin -shared -o Crapo.src -S -I "C:\Program
Files\Java\jdk1.6.0\include" -I "C:\Program
Files\Java\jdk1.6.0\include\win32" Crapo.c
//remove @12 from Crapo.src
//run as -o Crapo.obj Crapo.src
//run ld -shared -o Crapo.dll Crapo.obj
//run nm Crapo.dll
U .bss
U .data
10001000 t .text
10001000 T _Java_Crapo_magicNumber
10001010 T __CTOR_LIST__
10001018 T __DTOR_LIST__
10002000 A __RUNTIME_PSEUDO_RELOC_LIST_END__
10002000 A __RUNTIME_PSEUDO_RELOC_LIST__
10001010 T ___CTOR_LIST__
10001018 T ___DTOR_LIST__
//... more crap
// by manually removing the @12 from the assembly source produced by
gcc and then separately assembling and linking solves the problem.
//I like the fact that their are far fewer unnecessary symbolic names.
Yet I was hoping their was a one step command-line option to be sent,
like --add-stdcall-alias? Any reason that doesn't seem to work for me?
//It's my understanding that -Wl,--add-stdcall-alias command-line
option is sent to the linker by gcc, and then subsequently sent to
dlltool where the option should result in the @nn's being removed from
the table of symbolic names. Is this correct?

 
Remi Arntzen





PostPosted: 2006-11-13 11:48:00 Top

java-programmer >> jni gcc mangled names
Remi Arntzen wrote:
> //Crapo.java
> public class Crapo {
> static {
> System.loadLibrary("Crapo");
> }
> native public static int magicNumber(int n);
> public static void main(String... args) {
> System.out.println(magicNumber(246));
> }
> }
> //Crapo.c
> typedef long long __int64;//gcc doesn't recognize __int64
> #include "Crapo.h"
> /*
> * Class: Crapo
> * Method: magicNumber
> * Signature: (I)I
> */
> JNIEXPORT jint JNICALL Java_Crapo_magicNumber(JNIEnv * env, jclass c,
> jint n) {
> return 47;
> }
> //run gcc -mno-cygwin -Wl,--add-stdcall-alias -shared -o Crapo.dll -I
> "C:\Program Files\Java\jdk1.6.0\include" -I "C:\Program
> Files\Java\jdk1.6.0\include\win32" Crapo.c
> //output of nm Crapo.dll
> 10003040 b .bss
> 10003020 b .bss
> 10003000 b .bss
> //............ 30+ lines of this crap
> 1000505c i .idata$5
> //..........................
> 100011d0 T _DllMain@12
> 10001000 T _DllMainCRTStartup@12
> 100011c0 T _Java_Crapo_magicNumber@12//<-----------------
> 10001360 T __CTOR_LIST__
> 10001368 T __DTOR_LIST__
> U __RUNTIME_PSEUDO_RELOC_LIST_END__
> U __RUNTIME_PSEUDO_RELOC_LIST__
> //................... more crap; to me at least
>
> //it was my understanding that --add-stdcall-alias when passed to the
> linker should remove the @12 of _Java_Crapo_magicNumber@12
> //run gcc -mno-cygwin -shared -o Crapo.src -S -I "C:\Program
> Files\Java\jdk1.6.0\include" -I "C:\Program
> Files\Java\jdk1.6.0\include\win32" Crapo.c
> //remove @12 from Crapo.src
> //run as -o Crapo.obj Crapo.src
> //run ld -shared -o Crapo.dll Crapo.obj
> //run nm Crapo.dll
> U .bss
> U .data
> 10001000 t .text
> 10001000 T _Java_Crapo_magicNumber
> 10001010 T __CTOR_LIST__
> 10001018 T __DTOR_LIST__
> 10002000 A __RUNTIME_PSEUDO_RELOC_LIST_END__
> 10002000 A __RUNTIME_PSEUDO_RELOC_LIST__
> 10001010 T ___CTOR_LIST__
> 10001018 T ___DTOR_LIST__
> //... more crap
> // by manually removing the @12 from the assembly source produced by
> gcc and then separately assembling and linking solves the problem.
> //I like the fact that their are far fewer unnecessary symbolic names.
> Yet I was hoping their was a one step command-line option to be sent,
> like --add-stdcall-alias? Any reason that doesn't seem to work for me?
> //It's my understanding that -Wl,--add-stdcall-alias command-line
> option is sent to the linker by gcc, and then subsequently sent to
> dlltool where the option should result in the @nn's being removed from
> the table of symbolic names. Is this correct?

-Wl,--add-stdcall-alias still doesn't work which is VERY frustrating
but now I come back to this same problem and the same steps and "java
Crapo" works fine with "nm Crapo.dll" returning

[...]
10001000 T _DllMainCRTStartup@12
100011c0 T _Java_Crapo_magicNumber@12
10001360 T __CTOR_LIST__
[...]

and that frustates me even more.

I know --add-stdcall-alias is supposed to solve my problems, because it
works for other users
http://forum.java.sun.com/thread.jspa?threadID=470937&messageID=2414695
If anyone knows whats going on please inform me as too why
--add-stdcall-alias does not work, and why magicNumber@12 symbolic
names are now excepted by the same java run-time (I have not changed my
jdk or jre since my original posting as far as I know) and not for
other users.