Hi all
due to my porting work on GCJ I was confronted with CNI for some time and as
some of you know. I like CNI very much ... so much that I dont wan't to use JNI
any more for all of my own projects. :)
There is however a caveat: With the neat CNI in place the GIJ runtime will not
be able to make use of BC ABI compiled classes any longer. This limitation
bothers me since the time I was first introduced to it last year when I worked
on the 'lazy linker' issue.
Last week I woke up early with my mind being busy thinking about the reasons for
the limitation and how one could fix it. It quickly turned out that I need more
information about the reasons for the CNI issue.
I can't promise that I will be able to fix the issue soon but at least I can
gather all the information for it and put it into GCC's Wiki so I (or someone
else) can use that as a reference later.
So could any of you describe why CNI is not usable by interpreted and BC-ABI
compiled code?
And a few questions:
When trying to load a CNI SO in the runtime with System.loadLibrary() I get an
error about missing symbols. These symbols are all the things I used at the C++
level but which belong to the Java implementation. Why Java 'symbols' are
nowhere available for the linker is clear to me: They only exist as bytecode.
Can the following be a feasible solution for the above mentioned problem?
When a CNI SO is loaded and a symbol cannot be found, the runtime inspects the
symbol name, calculates the class/field/method which is requested. If it exists
a suitable accessor is created. Finally a symbol is dynamically created (is that
possible?) which points at the accessor.
The accessor for an interpreted Java method would be a libffi function call. For
a field it may be possible to use its address.
If symbols cannot be created dynamically is it possible to modify the places
where the symbol in question is used to point at another location?
Thanks for your explanations.