This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bootstrap failure on sparc-linux-gnu
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: ja2morri at csclub dot uwaterloo dot ca (James Morrison)
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 22 Apr 2004 17:48:59 +0200
- Subject: Re: Bootstrap failure on sparc-linux-gnu
- References: <20040422150115.B96A24BF01@carbonated-water.csclub.uwaterloo.ca>
> I looked at the assembly output of ada/ali.adb from the stage2 and stage3
> compiler and they are the same.
Not quite. The .text section is indeed the same, but this is not true for
all sections.
> However, I get the following differences
> from the actual object files:
>
> jim@squirrel:~/cvs/gcc.ssh/sparc-linux-20040421/gcc $ cmp -b
> --ignore-initial=16 ada/ali.o stage2/ada/ali.o ada/ali.o stage2/ada/ali.o
> differ: byte 35184, line 137 is 145 e 140 `
> jim@squirrel:~/cvs/gcc.ssh/sparc-linux-20040421/gcc $ cmp -b
> --ignore-initial=16 ada/ali-util.o stage2/ada/ali-util.o ada/ali-util.o
> stage2/ada/ali-util.o differ: byte 27042, line 76 is 20 ^P 22 ^R
Not very helpful :-)
> The differences for ali-util seem to be fairly extensive:
Because you picked a big file :-)
Here's what I get with butil.adb for the object file:
***************
*** 79,87 ****
0360 00000001 6e0b7500 05370000 01a80000 ....n.u..7......
0370 00000002 00000000 04070753 49474e45 ...........SIGNE
0380 445f3332 00040516 6e616d65 742e6e61 D_32....namet.na
! 0390 6d655f62 75666665 72000380 00000146 me_buffer......F
! 03a0 0101166e 616d6574 2e6e616d 655f6c65 ...namet.name_le
! 03b0 6e000387 0000009c 01011668 6f737470 n..........hostp
03c0 61726d2e 6f70656e 766d7300 06380000 arm.openvms..8..
03d0 006e0101 00 .n...
Contents of section .debug_line:
--- 79,87 ----
0360 00000001 6e0b7500 05370000 01a80000 ....n.u..7......
0370 00000002 00000000 04070753 49474e45 ...........SIGNE
0380 445f3332 00040516 6e616d65 742e6e61 D_32....namet.na
! 0390 6d655f6c 656e0003 87000000 9c010116 me_len..........
! 03a0 6e616d65 742e6e61 6d655f62 75666665 namet.name_buffe
! 03b0 72000380 00000146 01011668 6f737470 r......F...hostp
03c0 61726d2e 6f70656e 766d7300 06380000 arm.openvms..8..
03d0 006e0101 00 .n...
Contents of section .debug_line:
It's the .debug_info section.
For the assembly output:
*** butil_stage2.s Thu Apr 22 06:41:49 2004
--- butil_stage3.s Thu Apr 22 06:41:26 2004
***************
*** 1405,1421 ****
.byte 0x4
.byte 0x5
.byte 0x16
! .asciz "namet.name_buffer"
.byte 0x3
! .byte 0x80
! .uaword 0x143
.byte 0x1
.byte 0x1
.byte 0x16
! .asciz "namet.name_len"
.byte 0x3
! .byte 0x87
! .uaword 0x99
.byte 0x1
.byte 0x1
.byte 0x16
--- 1405,1421 ----
.byte 0x4
.byte 0x5
.byte 0x16
! .asciz "namet.name_len"
.byte 0x3
! .byte 0x87
! .uaword 0x99
.byte 0x1
.byte 0x1
.byte 0x16
! .asciz "namet.name_buffer"
.byte 0x3
! .byte 0x80
! .uaword 0x143
.byte 0x1
.byte 0x1
.byte 0x16
> Any clues as to how I can track down this failure?
A starting point would be to look at what dwarf2out.c is passed in both
cases.
--
Eric Botcazou