gcj and UDP datagrams under freebsd

[Bryce McKinlay]

Loren James Rittle wrote:

>I am fairly sure that the patch you sent to enforce 8 byte minimum
>alignment in gcj doesn't work for me.  Crash at startup is seen in the
>first call to _Jv_RegisterClassHookDefault called from
>_Jv_RegisterClasses (called from ELF-style _init):
>
>459       jint hash = HASH_UTF (klass->name);
>

Hmm, ok, after doing a full rebuild with my patch, I am seeing this too.

>Of course, I would print both klass and klass->name at this point to
>help determine what is wrong.
>
>I can't debug it any further with gdb since all I get is this message:
>
>	can't find class named `java::lang::Class', as given by C++ RTTI
>

GDB works OK for me BTW. Using "GNU gdb 2002-02-11-cvs" on PPC Linux.

>In case you know how to decode the layout of a Class (even looking at
>the order of the fields in java/lang/Class.h, I can't), here is the
>raw memory of the first entry in __JCR_LIST__ of the corrupt library:
>
>0x28513780 <_ZN4java4util3jar10Attributes6class$E>:     0x0804a5f0      0x00000000      0x00000000      0x284a9b10
>0x28513790 <_ZN4java4util3jar10Attributes6class$E+16>:  0x00000001      0x0804a578      0x00000002      0x284ef0c0
>

It depends if hash synchronization is in use or not. If not then the 
fields will be:

vtable
sync_info
next
name
...

all these are pointers.

Or if hash sychronization is used then they will be:

vtable
next
name
...


So if hash synchronization is in use then clearly the problem is that 
class->name is null. Inspection with GDB reveals that the class name is 
actually at class->name+4.  But I'm not sure how my patch would have 
caused this to happen!

>I proposed this new test case:
>
>	* libjava.lang/SyncGlobal.java, libjava.lang/SyncGlobal.out:
>	New test case.
>

Thanks, please check this in to mainline.

regards

Bryce.