Mixing BC and CNI in the same executable

Mixing BC and CNI in the same executable

[Stephen Kell]

I was hoping I could use BC to avoid compiling and linking a huge jar.so 
into my CNI C++ program (which only requires a few functions from the 
jar). Instead I want libgcj to load code from the jar at run time. My 
C++ code doesn't use anything in the jar directly.

Should this be possible?  I initially thought not, but it's not clear 
why. (Presumably libgcj uses one ABI or other itself, or exports both; 
either of these implies that the two can be mixed somehow....)

Anyway, having tried it, I'm having the following problem. I compiled 
the Java code which my CNI calls target (it happens to be the antlr 
runtime, and is packaged as another jar) with -findirect-dispatch. That 
works, but now my CNI code can't like with it, for reasons that aren't 
clear. Does an -findirect-dispatch binary still expose the right symbols 
for the "direct dispatch" ABI symbols?

Here's the failure I'm seeing (huge command, sorry).

gcj -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-type
s -fPIC -g3 --classpath=./java:/home/stephen/opt/lib/java/antlr-runtime-
3.1.3.jar:/usr/share/java/junit-3.8.2.jar:/home/stephen/opt/lib/java/str
ingtemplate-3.2.jar: -Wall  -L../../dwarf/libdwarfpp -L/home/stephen/opt
/lib -L../../c++-fileno/lib -L../../libsrk31c++ -o "cake" java/cake/Clon
eableTree.o java/cake/InternalError.o java/cake/SemanticError.o java/cak
e/TreewalkError.o alias.o cake.o cppcatch.o derive.o dwarf.o exists.o ja
vacatch.o link.o main.o module.o pred.o supplementary.o util.o ../../dwa
rf/libdwarfpp/libdwarfpp.a -lsrk31c++ -Wl,--whole-archive -ldwarf -Wl,--
no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ antlr-runtime.jar.so

java/cake/CloneableTree.o: In function `cake::CloneableTree::CloneableTr
ee(org::antlr::runtime::tree::Tree*)': /home/stephen/work/devel/cake/src
/cake/CloneableTree.java:11: undefined reference to `org::antlr::runtime
::tree::CommonTree::class$'
(snipped lots more)

The funny thing is that actually, the symbols do seem to be exported... 
maybe some linker magic is stopping them from being resolved?

$ objdump -t antlr-runtime.jar.so | c++filt | grep CommonTree::class
00083c00 l     O .rodata        00000090              org::antlr::runtime::tree::CommonTree::class$
000a4870 l     O .bss   00000004              .hidden org::antlr::runtime::tree::CommonTree::class$$

I'm guessing the answer is "it won't work" but thought I'd ask anyway. I 
can provide a tarball on request. Thanks for reading,

Stephen.

Re: Mixing BC and CNI in the same executable

[Bryce McKinlay]

On Sat, Jan 23, 2010 at 12:38 AM, Stephen Kell <srk31@srcf.ucam.org> wrote:
>
> I was hoping I could use BC to avoid compiling and linking a huge jar.so
> into my CNI C++ program (which only requires a few functions from the
> jar). Instead I want libgcj to load code from the jar at run time. My
> C++ code doesn't use anything in the jar directly.
>
> Should this be possible?  I initially thought not, but it's not clear
> why. (Presumably libgcj uses one ABI or other itself, or exports both;
> either of these implies that the two can be mixed somehow....)
>
> Anyway, having tried it, I'm having the following problem. I compiled
> the Java code which my CNI calls target (it happens to be the antlr
> runtime, and is packaged as another jar) with -findirect-dispatch. That
> works, but now my CNI code can't like with it, for reasons that aren't
> clear. Does an -findirect-dispatch binary still expose the right symbols
> for the "direct dispatch" ABI symbols?
>
> Here's the failure I'm seeing (huge command, sorry).
>
> gcj -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-type
> s -fPIC -g3 --classpath=./java:/home/stephen/opt/lib/java/antlr-runtime-
> 3.1.3.jar:/usr/share/java/junit-3.8.2.jar:/home/stephen/opt/lib/java/str
> ingtemplate-3.2.jar: -Wall  -L../../dwarf/libdwarfpp -L/home/stephen/opt
> /lib -L../../c++-fileno/lib -L../../libsrk31c++ -o "cake" java/cake/Clon
> eableTree.o java/cake/InternalError.o java/cake/SemanticError.o java/cak
> e/TreewalkError.o alias.o cake.o cppcatch.o derive.o dwarf.o exists.o ja
> vacatch.o link.o main.o module.o pred.o supplementary.o util.o ../../dwa
> rf/libdwarfpp/libdwarfpp.a -lsrk31c++ -Wl,--whole-archive -ldwarf -Wl,--
> no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ antlr-runtime.jar.so
>
> java/cake/CloneableTree.o: In function `cake::CloneableTree::CloneableTr
> ee(org::antlr::runtime::tree::Tree*)': /home/stephen/work/devel/cake/src
> /cake/CloneableTree.java:11: undefined reference to `org::antlr::runtime
> ::tree::CommonTree::class$'
> (snipped lots more)
>
> The funny thing is that actually, the symbols do seem to be exported...
> maybe some linker magic is stopping them from being resolved?
>
> $ objdump -t antlr-runtime.jar.so | c++filt | grep CommonTree::class
> 00083c00 l     O .rodata        00000090              org::antlr::runtime::tree::CommonTree::class$
> 000a4870 l     O .bss   00000004              .hidden org::antlr::runtime::tree::CommonTree::class$$
>
> I'm guessing the answer is "it won't work" but thought I'd ask anyway. I
> can provide a tarball on request. Thanks for reading,

It looks like the problem here is that antlr-runtime.jar.so was built
with BC, but the java code in your app binary was not. When using
BC-ABI (and specifically, -findirect-classes), the class$ symbols are
hidden.

Try building the Antlr .so with -findirect-dispatch
-fno-indirect-classes. This means that it's calls will be made with be
made with the BC ABI but class references will not - which is probably
ok most of the time.

I'd also build the java code in your app binary with
-findirect-dispatch -fno-indirect-classes.

Bryce

Re: Mixing BC and CNI in the same executable

[Andrew Haley]

On 23/01/10 09:32, Bryce McKinlay wrote:

> It looks like the problem here is that antlr-runtime.jar.so was built
> with BC, but the java code in your app binary was not. When using
> BC-ABI (and specifically, -findirect-classes), the class$ symbols are
> hidden.
> 
> Try building the Antlr .so with -findirect-dispatch
> -fno-indirect-classes. This means that it's calls will be made with be
> made with the BC ABI but class references will not - which is probably
> ok most of the time.
> 
> I'd also build the java code in your app binary with
> -findirect-dispatch -fno-indirect-classes.

And the application must be compiled -fpic.  Really important!

Andrew.

Re: Mixing BC and CNI in the same executable

[Stephen Kell]

> It looks like the problem here is that antlr-runtime.jar.so was built
> with BC, but the java code in your app binary was not. When using
> BC-ABI (and specifically, -findirect-classes), the class$ symbols are
> hidden.
> 
> Try building the Antlr .so with -findirect-dispatch
> -fno-indirect-classes. This means that it's calls will be made with be
> made with the BC ABI but class references will not - which is probably
> ok most of the time.
> 
> I'd also build the java code in your app binary with
> -findirect-dispatch -fno-indirect-classes.

Thanks very much for this -- those options got my program to build and
run. However, it falls over during run-time linking. In my C++ code:

34:	int request::process()
35:	{
36:		using namespace org::antlr::runtime;
37:		using namespace java::lang;
38:        
39:		// invoke the parser
40:		stream = new ANTLRInputStream(in_file);
41:		lexer = new cakeJavaLexer((CharStream*) stream);

... the second "new" segfaults. Strangely, the first "new" is okay. The
first is a class from a antlr-runtime.jar.so, whereas the second is in
a .o compiled from local source. They were both compiled with
-findirect-dispatch -fno-indirect-classes.

Program received signal SIGSEGV, Segmentation fault.
0xb6670fb1 in _Jv_ClosureList::registerClosure(java::lang::Class*, void*) ()
   from /usr/lib/libgcj_bc.so.1
(gdb) bt
#0  0xb6670fb1 in _Jv_ClosureList::registerClosure(java::lang::Class*, void*) ()
   from /usr/lib/libgcj_bc.so.1
#1  0xb6639389 in _Jv_Linker::create_error_method(_Jv_Utf8Const*, java::lang::Class*) ()
   from /usr/lib/libgcj_bc.so.1
#2  0xb663b423 in _Jv_Linker::link_symbol_table(java::lang::Class*) () from /usr/lib/libgcj_bc.so.1
#3  0xb663a85c in _Jv_Linker::wait_for_state(java::lang::Class*, int) ()
   from /usr/lib/libgcj_bc.so.1
#4  0xb6674930 in void java::lang::Class::initializeClass() () from /usr/lib/libgcj_bc.so.1
#5  0xb662a018 in _Jv_AllocObjectNoFinalizer () from /usr/lib/libgcj_bc.so.1
#6  0xb662a046 in _Jv_AllocObject () from /usr/lib/libgcj_bc.so.1
#7  0x08052c7b in cake::request::process (this=0xbffff00c) at cake.cpp:41
#8  0x08057a08 in main (argc=2, argv=0xbffff114) at main.cpp:62

Thanks again for any further suggestions! 

(I only just noticed that the BC libgcj is a completely different
shared object... so perhaps mixing ABIs is a non-starter as I feared.)

Stephen

Re: Mixing BC and CNI in the same executable

[Andrew Haley]

On 01/23/2010 02:51 PM, Stephen Kell wrote:
>> It looks like the problem here is that antlr-runtime.jar.so was built
>> with BC, but the java code in your app binary was not. When using
>> BC-ABI (and specifically, -findirect-classes), the class$ symbols are
>> hidden.
>>
>> Try building the Antlr .so with -findirect-dispatch
>> -fno-indirect-classes. This means that it's calls will be made with be
>> made with the BC ABI but class references will not - which is probably
>> ok most of the time.
>>
>> I'd also build the java code in your app binary with
>> -findirect-dispatch -fno-indirect-classes.
> 
> Thanks very much for this -- those options got my program to build and
> run. However, it falls over during run-time linking. In my C++ code:
> 
> 34:	int request::process()
> 35:	{
> 36:		using namespace org::antlr::runtime;
> 37:		using namespace java::lang;
> 38:        
> 39:		// invoke the parser
> 40:		stream = new ANTLRInputStream(in_file);
> 41:		lexer = new cakeJavaLexer((CharStream*) stream);
> 
> ... the second "new" segfaults. Strangely, the first "new" is okay. The
> first is a class from a antlr-runtime.jar.so, whereas the second is in
> a .o compiled from local source. They were both compiled with
> -findirect-dispatch -fno-indirect-classes.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6670fb1 in _Jv_ClosureList::registerClosure(java::lang::Class*, void*) ()
>    from /usr/lib/libgcj_bc.so.1
> (gdb) bt
> #0  0xb6670fb1 in _Jv_ClosureList::registerClosure(java::lang::Class*, void*) ()
>    from /usr/lib/libgcj_bc.so.1
> #1  0xb6639389 in _Jv_Linker::create_error_method(_Jv_Utf8Const*, java::lang::Class*) ()
>    from /usr/lib/libgcj_bc.so.1
> #2  0xb663b423 in _Jv_Linker::link_symbol_table(java::lang::Class*) () from /usr/lib/libgcj_bc.so.1
> #3  0xb663a85c in _Jv_Linker::wait_for_state(java::lang::Class*, int) ()
>    from /usr/lib/libgcj_bc.so.1
> #4  0xb6674930 in void java::lang::Class::initializeClass() () from /usr/lib/libgcj_bc.so.1
> #5  0xb662a018 in _Jv_AllocObjectNoFinalizer () from /usr/lib/libgcj_bc.so.1
> #6  0xb662a046 in _Jv_AllocObject () from /usr/lib/libgcj_bc.so.1
> #7  0x08052c7b in cake::request::process (this=0xbffff00c) at cake.cpp:41
> #8  0x08057a08 in main (argc=2, argv=0xbffff114) at main.cpp:62
> 
> Thanks again for any further suggestions! 
> 
> (I only just noticed that the BC libgcj is a completely different
> shared object... so perhaps mixing ABIs is a non-starter as I feared.)

You should be OK.  Tell us how you linked it all.

Andrew.

Re: Mixing BC and CNI in the same executable

[Stephen Kell]

> You should be OK.  Tell us how you linked it all.

Here's the command that builds my executable (somewhat wrapped).

gcj -fno-eliminate-unused-debug-symbols
-fno-eliminate-unused-debug-types -findirect-dispatch
-fno-indirect-classes -fpic -g3
--classpath=./java:/home/stephen/work/devel/cake/src/antlr-runtime-3.1.3.jar:/home/stephen/opt/lib/java/antlr-3.1.3.jar:
-Wall  -L../../dwarf/libdwarfpp/src -L/home/stephen/opt/lib
-L../../c++-fileno/lib -L../../libsrk31c++ -Wl,-R.
java/cake/CloneableTree.o java/cake/InternalError.o
java/cake/SemanticError.o java/cake/TreewalkError.o  alias.o cake.o
cppcatch.o derive.o dwarf.o exists.o javacatch.o link.o main.o module.o
pred.o supplementary.o util.o  parser/parser.a  antlr-runtime.jar.so
stringtemplate.jar.so -lsrk31c++ -Wl,--whole-archive -ldwarf
-Wl,--no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ -o "cake" 

I had been compiling with -fPIC. I tried changing it to -fpic just in
case, but no change. I've pasted a larger tail-end chunk of my build
log below, showing gcj and g++ compiler invocations.

Stephen

g++ -c -o "util.o" -fno-eliminate-unused-debug-symbols
-fno-eliminate-unused-debug-types -fpic -g3 -Iparser/include -Iinclude
-Ijava/include -I../../dwarf/libdwarfpp/include -I../../libsrk31c++
-I../../c++-fileno/include -I/home/stephen/opt/include  -Wall
-DCAKE_VERSION=\"0.0201001231743\" "util.cpp"
gcj -shared -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -findirect-dispatch -fno-indirect-classes -fpic -g3 --classpath=./java:/home/stephen/work/devel/cake/src/antlr-runtime-3.1.3.jar:/home/stephen/opt/lib/java/antlr-3.1.3.jar:  -Wall  -o "antlr-runtime.jar.so" "antlr-runtime-3.1.3.jar"
gcj -shared -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -findirect-dispatch -fno-indirect-classes -fpic -g3 --classpath=./java:/home/stephen/work/devel/cake/src/antlr-runtime-3.1.3.jar:/home/stephen/opt/lib/java/antlr-3.1.3.jar:  -Wall  -o "stringtemplate.jar.so" "stringtemplate-3.2.1.jar"
gcj -fno-eliminate-unused-debug-symbols
-fno-eliminate-unused-debug-types -findirect-dispatch
-fno-indirect-classes -fpic -g3
--classpath=./java:/home/stephen/work/devel/cake/src/antlr-runtime-3.1.3.jar:/home/stephen/opt/lib/java/antlr-3.1.3.jar:
-Wall  -L../../dwarf/libdwarfpp/src -L/home/stephen/opt/lib
-L../../c++-fileno/lib -L../../libsrk31c++ -Wl,-R.
java/cake/CloneableTree.o java/cake/InternalError.o
java/cake/SemanticError.o java/cake/TreewalkError.o  alias.o cake.o
cppcatch.o derive.o dwarf.o exists.o javacatch.o link.o main.o module.o
pred.o supplementary.o util.o  parser/parser.a  antlr-runtime.jar.so
stringtemplate.jar.so -lsrk31c++ -Wl,--whole-archive -ldwarf
-Wl,--no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ -o "cake" 

Re: Mixing BC and CNI in the same executable

[Andrew Haley]

On 01/25/2010 01:09 PM, Stephen Kell wrote:
>> You should be OK.  Tell us how you linked it all.
> 
> Here's the command that builds my executable (somewhat wrapped).
> 
> gcj -fno-eliminate-unused-debug-symbols
> -fno-eliminate-unused-debug-types -findirect-dispatch
> -fno-indirect-classes -fpic -g3
> --classpath=./java:/home/stephen/work/devel/cake/src/antlr-runtime-3.1.3.jar:/home/stephen/opt/lib/java/antlr-3.1.3.jar:
> -Wall  -L../../dwarf/libdwarfpp/src -L/home/stephen/opt/lib
> -L../../c++-fileno/lib -L../../libsrk31c++ -Wl,-R.
> java/cake/CloneableTree.o java/cake/InternalError.o
> java/cake/SemanticError.o java/cake/TreewalkError.o  alias.o cake.o
> cppcatch.o derive.o dwarf.o exists.o javacatch.o link.o main.o module.o
> pred.o supplementary.o util.o  parser/parser.a  antlr-runtime.jar.so
> stringtemplate.jar.so -lsrk31c++ -Wl,--whole-archive -ldwarf
> -Wl,--no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ -o "cake" 
> 
> I had been compiling with -fPIC. I tried changing it to -fpic just in
> case, but no change. I've pasted a larger tail-end chunk of my build
> log below, showing gcj and g++ compiler invocations.

Thanks.

I've seen something like this years ago, but I can't remember what
caused it.  I expect it's something quite simple, but I can't tell
from what you've posted here.

If you can make a self-contained test case theat reproduces the
problem I'll debug it.

Andrew.

Re: Mixing BC and CNI in the same executable

[Stephen Kell]

> Thanks.
> 
> I've seen something like this years ago, but I can't remember what
> caused it.  I expect it's something quite simple, but I can't tell
> from what you've posted here.
> 
> If you can make a self-contained test case theat reproduces the
> problem I'll debug it.

Great -- thanks! The following tarball *should* be self-contained...
"make testcase" should trigger the bug.

http://www.cl.cam.ac.uk/~srk31/private/testcase-20100125.tar.bz2

Stephen

Re: Mixing BC and CNI in the same executable

[Andrew Haley]

On 01/25/2010 03:45 PM, Stephen Kell wrote:
>> Thanks.
>>
>> I've seen something like this years ago, but I can't remember what
>> caused it.  I expect it's something quite simple, but I can't tell
>> from what you've posted here.
>>
>> If you can make a self-contained test case theat reproduces the
>> problem I'll debug it.
> 
> Great -- thanks! The following tarball *should* be self-contained...
> "make testcase" should trigger the bug.
> 
> http://www.cl.cam.ac.uk/~srk31/private/testcase-20100125.tar.bz2

It's a combination of bugs.  Firstly, there's a bug in libgcj when a
needed class is not found in an executable: it causes a crash when
trying to report the problem.  Fixed thusly:

Index: java/lang/natClass.cc
===================================================================
--- java/lang/natClass.cc	(revision 156043)
+++ java/lang/natClass.cc	(working copy)
@@ -689,9 +689,12 @@
 _Jv_ClosureList::registerClosure (jclass klass, void *ptr)
 {
   _Jv_ClosureList **closures = klass->engine->get_closure_list (klass);
-  this->ptr = ptr;
-  this->next = *closures;
-  *closures = this;
+  if (closures)
+    {
+      this->ptr = ptr;
+      this->next = *closures;
+      *closures = this;
+    }
 }
 #endif
 
Secondly, you don't catch errors in your main program, just exceptions,
so you won't see Errors.  Do this instead:

		catch (java::lang::Throwable *e)
		{
			java::lang::System::err->print(e->toString());
			return 1;
		}				

Thirdly, you aren't linking in inner classes.  This works for me:

 gcj -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -findirect-dispatch -fno-indirect-classes -fpic -g3 --classpath=./java:./antlr-runtime-3.1.3.jar:: -Wall   -Wl,-R.   cake.o main.o  parser/parser.a antlr-runtime.jar.so stringtemplate.jar.so  -lstdc++ -o "cake" -Wl,-Map,map java/cake/TreewalkError.o java/cake/InternalError.o java/cake/CloneableTree.o java/cake/SemanticError.o ./parser/cake/cakeJavaParser\$DFA*.o ./parser/cake/cakeJavaLexer\$DFA*.o ./parser/cake/cakeJavaParser\$*_return.o 

It would be better to compile from .java -> .o, and then you would not
have to worry about all the inner classes.

Andrew.

Re: Mixing BC and CNI in the same executable

[Stephen Kell]

> It's a combination of bugs.  Firstly, there's a bug in libgcj when a
> needed class is not found in an executable: it causes a crash when
> trying to report the problem.  Fixed thusly:

Thanks very much for this! My program does indeed now run as it's
supposed to (i.e. back to coding...).

> Thirdly, you aren't linking in inner classes.  This works for me:
> 
>  gcj -fno-eliminate-unused-debug-symbols
> -fno-eliminate-unused-debug-types -findirect-dispatch
> -fno-indirect-classes -fpic -g3
> --classpath=./java:./antlr-runtime-3.1.3.jar:: -Wall   -Wl,-R.
> cake.o main.o  parser/parser.a antlr-runtime.jar.so
> stringtemplate.jar.so  -lstdc++ -o "cake" -Wl,-Map,map
> java/cake/TreewalkError.o java/cake/InternalError.o
> java/cake/CloneableTree.o
> java/cake/SemanticError.o ./parser/cake/cakeJavaParser\$DFA*.o ./parser/cake/cakeJavaLexer\$DFA*.o ./parser/cake/cakeJavaParser\$*_return.o 
> 
> It would be better to compile from .java -> .o, and then you would not
> have to worry about all the inner classes.

Aha... I had been stuffing all the .o files (including inner classes)
into parser.a, hoping it would be sufficient to link with that, but
clearly this was a bad plan. (I guess only symbols with link-time
references get linked... meanwhile --whole-archive fails because of
multiple definitions of others.)

Thanks again,
Stephen.

Re: Mixing BC and CNI in the same executable

[Andrew Haley]

On 01/26/2010 05:06 PM, Stephen Kell wrote:
>> It's a combination of bugs.  Firstly, there's a bug in libgcj when a
>> needed class is not found in an executable: it causes a crash when
>> trying to report the problem.  Fixed thusly:
> 
> Thanks very much for this! My program does indeed now run as it's
> supposed to (i.e. back to coding...).

Great.  Let us know how you get on: we're always interested to hear
about people using gcj.

Andrew.