PPC constant merging problem
Bryce McKinlay
bryce@waitaki.otago.ac.nz
Sat Feb 16 21:53:00 GMT 2002
Hi Jakub,
Sorry for taking so long to get back to you on this. To try and track
this down a bit I added some printf's in my libgcj tree, in
_Jv_PrepareCompiledClass and _Jv_NewStringUtf8Const. The first few lines
of correct output from these for a libgcj with constant merging disabled
(in java/class.c:build_utf8_ref) are:
$ gcj Hello.java --main=Hello
$ ./a.out | more
_Jv_PrepareCompiledClass() java.lang.Class
_Jv_NewStringUtf8Const()
_Jv_PrepareCompiledClass() java.lang.String
_Jv_NewStringUtf8Const() 8859_1
_Jv_PrepareCompiledClass() java.lang.reflect.Modifier
_Jv_NewStringUtf8Const() public
_Jv_PrepareCompiledClass() java.lang.Object
With an identical tree but with constant merging enabled, I get:
$ ./a.out
_Jv_PrepareCompiledClass() getClassLoader
_Jv_NewStringUtf8Const() /
_Jv_PrepareCompiledClass() hash
_Jv_NewStringUtf8Const() ([C)V
_Jv_PrepareCompiledClass() java.lang.reflect.Modifier
_Jv_NewStringUtf8Const() ang.reflect.Method
Segmentation fault (core dumped)
"getClassLoader" and "hash" are strings that occur in libgcj, but they
are not class names and should certainly not be appearing in my
PrepareCompiledClass() printf! However the third one is correct.
So it seems many but not all of the Utf8Const pointers are either
pointing to the wrong Utf8Const or pointing to random data inside one.
Here is the readelf -S output for one .o file from libgcj:
$ readelf -S java/lang/reflect/.libs/Method.o
There are 39 section headers, starting at offset 0x2c34:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 00000000 000034 0006c4 00 AX
0 0 4
[ 2] .rela.text RELA 00000000 004178 000318 0c
37 1 4
[ 3] .data PROGBITS 00000000 0006f8 000234 00 WA
0 0 4
[ 4] .rela.data RELA 00000000 004490 0003cc 0c
37 3 4
[ 5] .bss NOBITS 00000000 00092c 000000 00 WA
0 0 1
[ 6] .stab PROGBITS 00000000 00092c 000840 0c
8 0 4
[ 7] .rela.stab RELA 00000000 00485c 000090 0c
37 6 4
[ 8] .stabstr STRTAB 00000000 00116c 0012cc 00
0 0 1
[ 9] .got2 PROGBITS 00000000 002438 00001c 00 WA
0 0 1
[10] .rela.got2 RELA 00000000 0048ec 000054 0c
37 9 4
[11] .rodata.jutf8.20 PROGBITS 00000000 002454 000050 14 AM
0 0 2
[12] .rodata.jutf8.24 PROGBITS 00000000 0024a4 000030 18 AM
0 0 2
[13] .rodata.jutf8.10 PROGBITS 00000000 0024d4 00000a 0a AM
0 0 2
[14] .rodata.jutf8.16 PROGBITS 00000000 0024de 000010 10 AM
0 0 2
[15] .rodata.jutf8.12 PROGBITS 00000000 0024ee 000048 0c AM
0 0 2
[16] .fixup PROGBITS 00000000 002538 00014c 00 WA
0 0 4
[17] .rela.fixup RELA 00000000 004940 0003e4 0c
37 10 4
[18] .rodata.jutf8.26 PROGBITS 00000000 002684 00004e 1a AM
0 0 2
[19] .rodata.jutf8.22 PROGBITS 00000000 0026d2 000042 16 AM
0 0 2
[20] .rodata.jutf8.18 PROGBITS 00000000 002714 000024 12 AM
0 0 2
[21] .rodata.jutf8.8 PROGBITS 00000000 002738 000018 08 AM
0 0 2
[22] .rodata.jutf8.14 PROGBITS 00000000 002750 00002a 0e AM
0 0 2
[23] .rodata.jutf8.62 PROGBITS 00000000 00277a 00003e 3e AM
0 0 2
[24] .rodata.jutf8.40 PROGBITS 00000000 0027b8 000028 28 AM
0 0 2
[25] .rodata.jutf8.42 PROGBITS 00000000 0027e0 00002a 2a AM
0 0 2
[26] .rodata.jutf8.50 PROGBITS 00000000 00280a 000064 32 AM
0 0 2
[27] .rodata.jutf8.6 PROGBITS 00000000 00286e 00001e 06 AM
0 0 2
[28] .rodata.jutf8.30 PROGBITS 00000000 00288c 00001e 1e AM
0 0 2
[29] .jcr PROGBITS 00000000 0028ac 000004 00 WA
0 0 4
[30] .rela.jcr RELA 00000000 004d24 00000c 0c
37 1d 4
[31] .eh_frame PROGBITS 00000000 0028b0 000194 00 WA
0 0 4
[32] .rela.eh_frame RELA 00000000 004d30 000078 0c
37 1f 4
[33] .gnu.linkonce.s.D PROGBITS 00000000 002a44 000004 00 WA
0 0 4
[34] .rela.gnu.linkonc RELA 00000000 004da8 00000c 0c
37 21 4
[35] .comment PROGBITS 00000000 002a48 000028 00
0 0 1
[36] .shstrtab STRTAB 00000000 002a70 0001c2 00
0 0 1
[37] .symtab SYMTAB 00000000 00324c 000740 10
38 4a 4
[38] .strtab STRTAB 00000000 00398c 0007ec 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Bryce.
Jakub Jelinek wrote:
>On Tue, Feb 05, 2002 at 03:00:30PM +1300, Bryce McKinlay wrote:
>
>>I have some bad news. The patch is working fine on x86 but seems to be
>>broken on PowerPC, using the same compiler and binutils versions.
>>
>>Symptom is the same as before: "hello world" dies very early while the
>>runtime is trying to initialize some Strings from Utf8 values:
>>
>>Starting program: /home/bryce/./a.out
>>[New Thread 1024 (LWP 6620)]
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>[Switching to Thread 1024 (LWP 6620)]
>>_Jv_NewStringUtf8Const(_Jv_Utf8Const*) (str=0xffffffff)
>> at ../../../libjava/java/lang/natString.cc:271
>>271 *chrs++ = ch;
>>Current language: auto; currently c++
>>
>>
>>(gdb) p str->hash
>>$2 = 30305
>>(gdb) p str->length
>>$3 = 11884
>>(gdb) printf "%s\n", str->data
>>ang.reflect.Method
>>
>>$ ld --version
>>GNU ld version 2.11.92.0.12.3 20011121
>>
>>Any ideas?
>>
>
>Can you track it down to a particular Utf8 constant (= the .o file this came
>from and _UtfN (local) name)? What does readelf -S show on that .o file?
>
> Jakub
>
More information about the Gcc
mailing list