This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PPC constant merging problem


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
>




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]