public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* gcj on OpenBSD
@ 2009-03-11 15:02 Kurt Miller
  2009-03-11 16:53 ` Andrew Haley
  0 siblings, 1 reply; 4+ messages in thread
From: Kurt Miller @ 2009-03-11 15:02 UTC (permalink / raw)
  To: java

Hi,

I've been working on getting gcj up and running on OpenBSD/i386.
Currently I'm working on adding gcj to gcc 4.2 port. I'm pretty far
along with the work: enabled dwarf2 exceptions, thread model posix, etc.
The build completes but gcj-dbtool segfaults and gij too. The segfault
occurs when initializing the class loader because engine is null.

Program received signal SIGSEGV, Segmentation fault.
0x03db9548 in _Jv_Linker::verify_class (klass=@236164a0)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/link.cc:1820
1820      klass->engine->verify(klass);
(gdb) p klass->engine
$1 = (_Jv_ExecutionEngine *) 0x0
(gdb) bt
#0  0x03db9548 in _Jv_Linker::verify_class (klass=@236164a0)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/link.cc:1820
#1  0x03dbb2a1 in _Jv_Linker::wait_for_state (klass=@236164a0, state=9)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/link.cc:1985
#2  0x03de3b90 in java::lang::Class::initializeClass (this=@236164a0)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/java/lang/natClass.cc:695
#3  0x03dac322 in _Jv_CreateJavaVM (vm_args=null) at Class.h:651
#4  0x03dacc2c in _Jv_RunMain (vm_args=null, klass=@3c0de280, name=null,
    argc=3, argv=@cfbc8a08, is_jar=false)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/prims.cc:1520
#5  0x03dace8b in _Jv_RunMain (klass=@3c0de280, name=null, argc=3,
    argv=@cfbc8a08, is_jar=Variable "is_jar" is not available.
)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/prims.cc:1593
#6  0x03daceb9 in JvRunMain (klass=@3c0de280, argc=3, argv=@cfbc8a08)
    at
/usr/obj/i386/ports/gcc-4.2.20070307.java/gcc-4.2-20070307/libjava/prims.cc:1599
#7  0x1c002cb9 in main (argc=Cannot access memory at address 0x1
) at /tmp//cceCHhDF.i:11



(gdb) set lang java
Warning: the current language does not match this frame.
(gdb) p *klass
$2 = {<java::lang::Object> = {<_JvObjectPrefix> = {
      _vptr$_JvObjectPrefix: @2ccc5d08}, static class$: @2ccc65c0,
    sync_info: @3c107fd8}, static class$: @2ccc6300,
  next_or_version: @40062250, name: @2cb533fc, accflags: 1025,
  superclass: @2ccc65c0, constants: {size: 9, tags: @2ce33fc0,
    data: @2ce40740}, : {methods = @2ce371e0, element_type = @2ce371e0},
  method_count: 35, vtable_method_count: 31, fields: @2ce37120,
  size_in_bytes: 32, field_count: 11, static_field_count: 4,
  vtable: @2ce37088, otable: null, otable_syms: null, atable: null,
  atable_syms: null, itable: null, itable_syms: null,
  catch_classes: @2ce33fcc, interfaces: null, loader: null,
  interface_count: 0, state: 7, thread: null, depth: 1, ancestors:
@3c10aff8,
  : {idt = null, ioffsets = null}, arrayclass: null, protectionDomain: null,
  assertion_table: null, hack_signers: null, chain: null, aux_info: null,
  engine: null}

Also superclass (java::lang::Object) engine is null too:

(gdb) p *klass.superclass
$4 = {<java::lang::Object> = {<_JvObjectPrefix> = {
      _vptr$_JvObjectPrefix: @2ccc5d08}, static class$: @2ccc65c0,
    sync_info: @3c107fc0}, static class$: @2ccc6300,
  next_or_version: @40062250, name: @2ca7f642, accflags: 1, superclass:
null,
  constants: {size: 2, tags: @2ccc6444, data: @2ccc6678}, : {
    methods = @2ccc64a0, element_type = @2ccc64a0}, method_count: 14,
  vtable_method_count: 6, fields: null, size_in_bytes: 8, field_count: 0,
  static_field_count: 0, vtable: @2ccc6468, otable: null, otable_syms: null,
  atable: null, atable_syms: null, itable: null, itable_syms: null,
  catch_classes: @2ccc6448, interfaces: null, loader: null,
  interface_count: 0, state: 3, thread: null, depth: 0, ancestors: null, : {
    idt = null, ioffsets = null}, arrayclass: null, protectionDomain: null,
  assertion_table: null, hack_signers: null, chain: null, aux_info: null,
  engine: null}

Could anyone suggest some ideas for diagnosing the root cause of this?

Thanks,
-Kurt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gcj on OpenBSD
  2009-03-11 15:02 gcj on OpenBSD Kurt Miller
@ 2009-03-11 16:53 ` Andrew Haley
  2009-03-11 16:57   ` Andrew Haley
  2009-03-11 20:14   ` Kurt Miller
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Haley @ 2009-03-11 16:53 UTC (permalink / raw)
  To: Kurt Miller; +Cc: java

Kurt Miller wrote:

> I've been working on getting gcj up and running on OpenBSD/i386.
> Currently I'm working on adding gcj to gcc 4.2 port. I'm pretty far
> along with the work: enabled dwarf2 exceptions, thread model posix, etc.
> The build completes but gcj-dbtool segfaults and gij too. The segfault
> occurs when initializing the class loader because engine is null.
> 
> Could anyone suggest some ideas for diagnosing the root cause of this?

This happens because class registration hasn't been done.  gcc generates
a magic section called .jcr, and this is a list of pointers to classes.

On x86_64 a .jcr section in an .o file with two classes looks like this:

RELOCATION RECORDS FOR [.jcr]:
OFFSET           TYPE              VALUE
0000000000000000 R_X86_64_64       P::class$
0000000000000008 R_X86_64_64       Hello::class$

And the .init section:

0000000000400bb0 <_init>:
  400bb0:       48 83 ec 08             sub    $0x8,%rsp
  400bb4:       e8 63 01 00 00          callq  400d1c <call_gmon_start>
  400bb9:       e8 f2 01 00 00          callq  400db0 <frame_dummy>
  400bbe:       e8 2d 04 00 00          callq  400ff0 <__do_global_ctors_aux>
  400bc3:       48 83 c4 08             add    $0x8,%rsp
  400bc7:       c3                      retq

which calls (*_Jv_RegisterClasses)

0000000000400db0 <frame_dummy>:
  400db0:       55                      push   %rbp
  400db1:       48 83 3d 87 04 20 00    cmpq   $0x0,0x200487(%rip)        # 601240 <__JCR_LIST__>
  400db8:       00
  400db9:       48 89 e5                mov    %rsp,%rbp
  400dbc:       74 1a                   je     400dd8 <frame_dummy+0x28>
  400dbe:       41 bb 18 0c 40 00       mov    $0x400c18 <_Jv_RegisterClasses@plt>,%r11d
  400dc4:       4d 85 db                test   %r11,%r11
  400dc7:       74 0f                   je     400dd8 <frame_dummy+0x28>
  400dc9:       bf 40 12 60 00          mov    $0x601240 <__JCR_LIST__>,%edi
  400dce:       c9                      leaveq
  400dcf:       41 ff e3                jmpq   *%r11
  400dd2:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
  400dd8:       c9                      leaveq
  400dd9:       c3                      retq

I suspect that this mechanism is not working on BSD.

Andrew.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gcj on OpenBSD
  2009-03-11 16:53 ` Andrew Haley
@ 2009-03-11 16:57   ` Andrew Haley
  2009-03-11 20:14   ` Kurt Miller
  1 sibling, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2009-03-11 16:57 UTC (permalink / raw)
  To: Kurt Miller; +Cc: java

Andrew Haley wrote:
> Kurt Miller wrote:
> 
>> I've been working on getting gcj up and running on OpenBSD/i386.
>> Currently I'm working on adding gcj to gcc 4.2 port. I'm pretty far
>> along with the work: enabled dwarf2 exceptions, thread model posix, etc.
>> The build completes but gcj-dbtool segfaults and gij too. The segfault
>> occurs when initializing the class loader because engine is null.
>>
>> Could anyone suggest some ideas for diagnosing the root cause of this?
> 
> This happens because class registration hasn't been done.  gcc generates
> a magic section called .jcr, and this is a list of pointers to classes.
> 
> On x86_64 a .jcr section in an .o file with two classes looks like this:
> 
> RELOCATION RECORDS FOR [.jcr]:
> OFFSET           TYPE              VALUE
> 0000000000000000 R_X86_64_64       P::class$
> 0000000000000008 R_X86_64_64       Hello::class$
> 
> And the .init section:

Of an executable, I mean.  There is no init section in the .o file.

> 0000000000400bb0 <_init>:
>   400bb0:       48 83 ec 08             sub    $0x8,%rsp
>   400bb4:       e8 63 01 00 00          callq  400d1c <call_gmon_start>
>   400bb9:       e8 f2 01 00 00          callq  400db0 <frame_dummy>
>   400bbe:       e8 2d 04 00 00          callq  400ff0 <__do_global_ctors_aux>
>   400bc3:       48 83 c4 08             add    $0x8,%rsp
>   400bc7:       c3                      retq
> 
> which calls (*_Jv_RegisterClasses)
> 
> 0000000000400db0 <frame_dummy>:
>   400db0:       55                      push   %rbp
>   400db1:       48 83 3d 87 04 20 00    cmpq   $0x0,0x200487(%rip)        # 601240 <__JCR_LIST__>
>   400db8:       00
>   400db9:       48 89 e5                mov    %rsp,%rbp
>   400dbc:       74 1a                   je     400dd8 <frame_dummy+0x28>
>   400dbe:       41 bb 18 0c 40 00       mov    $0x400c18 <_Jv_RegisterClasses@plt>,%r11d
>   400dc4:       4d 85 db                test   %r11,%r11
>   400dc7:       74 0f                   je     400dd8 <frame_dummy+0x28>
>   400dc9:       bf 40 12 60 00          mov    $0x601240 <__JCR_LIST__>,%edi
>   400dce:       c9                      leaveq
>   400dcf:       41 ff e3                jmpq   *%r11
>   400dd2:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
>   400dd8:       c9                      leaveq
>   400dd9:       c3                      retq
> 
> I suspect that this mechanism is not working on BSD.
> 
> Andrew.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gcj on OpenBSD
  2009-03-11 16:53 ` Andrew Haley
  2009-03-11 16:57   ` Andrew Haley
@ 2009-03-11 20:14   ` Kurt Miller
  1 sibling, 0 replies; 4+ messages in thread
From: Kurt Miller @ 2009-03-11 20:14 UTC (permalink / raw)
  To: Andrew Haley; +Cc: java

Andrew Haley wrote:
> Kurt Miller wrote:
> 
>> I've been working on getting gcj up and running on OpenBSD/i386.
>> Currently I'm working on adding gcj to gcc 4.2 port. I'm pretty far
>> along with the work: enabled dwarf2 exceptions, thread model posix, etc.
>> The build completes but gcj-dbtool segfaults and gij too. The segfault
>> occurs when initializing the class loader because engine is null.
>>
>> Could anyone suggest some ideas for diagnosing the root cause of this?
> 
> This happens because class registration hasn't been done.  gcc generates
> a magic section called .jcr, and this is a list of pointers to classes.
> 

...

> I suspect that this mechanism is not working on BSD.

Ahh thanks. Yes we didn't have the _Jv_RegisterClasses hooks in our csu
objects. I added them and I see _Jv_RegisterClasses being called for
gcj-dbtool. However, my libgcj.so doesn't have .init section so
_Jv_RegisterClasses is not being called for it (linked with -nostdlib),
so I still segfault. Hacking -nostdlib out of libtool fixes that for me
and gcj-dbtool doesn't segfault anymore.

I think I may have caused the no .init issue with a patch to ltconfig
for a problem I hit earlier with predep_objects. It looks like
crtbeginS.o may be linked via predep_objects but I removed that. Time
to revert that change and find out...

Thanks for the help, I'm making progress again.

-Kurt

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-03-11 20:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-11 15:02 gcj on OpenBSD Kurt Miller
2009-03-11 16:53 ` Andrew Haley
2009-03-11 16:57   ` Andrew Haley
2009-03-11 20:14   ` Kurt Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).