[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #9 from Dennis Clarke --- If I remove the "go" language from the mix then I get reasonable results : https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02064.html I will install that and then try again with the "all" languages selection after stage1.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #8 from Dennis Clarke --- (In reply to Eric Botcazou from comment #7) > See PR bootstrap/77995 for a similar issue on x86-64/Solaris. Looks like a distant relation at best. That seemed to have something to do with complex types and build_complex_type() requiring a second "named" bool parameter. In the same ballpark perhaps but only as the ballboy selling hot dogs watching the game. My bootstrap of 7.2.0 did complete fine and the testsuite is running. I think I shall circle back to 6.4.0 and try a bootstrap with "go" as an enabled language after stage1 and see what happens. On sparc only. I could try this on Solaris x86_64 but I don't have any of that around and have not seen it in the wild for some years.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #7 from Eric Botcazou --- See PR bootstrap/77995 for a similar issue on x86-64/Solaris.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #6 from Eric Botcazou --- > elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2: > > Section Header[37]: sh_name: .debug_info > sh_addr: 0 sh_flags: 0 > sh_size: 0x1636a2sh_type:[ SHT_PROGBITS ] > sh_offset:0x1faa0 sh_entsize: 0 > sh_link: 0 sh_info:0 > sh_addralign: 0x1 > > Whereas stage3 reports : > > Section Header[37]: sh_name: .debug_info > sh_addr: 0 sh_flags: 0 > sh_size: 0x163698sh_type:[ SHT_PROGBITS ] > sh_offset:0x1faa0 sh_entsize: 0 > sh_link: 0 sh_info:0 > sh_addralign: 0x1 > > > Not exactly 8 bytes. Looks like 10 bytes diff. All other "sh_size" section > size data matches. OK, thanks, this rings a bell. Unlike other platforms, the bootstrap process on Solaris involves comparing the debug info, so things like this might go unnoticed by the developers using other platforms.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #5 from Dennis Clarke --- Minor note, the gcc 6.4.0 compiler I am using was not built with support for "go". I rarely ever build "go" as I have never had a use for it however I really should. It is possible some small bug has slipped under the radar because I just did a three stage bootstrap of 7.2.0 without "go" with success. Perhaps something subtle at work strictly in the "go" code area. I will run a testsuite and then get back to perhaps a build with stage1 languages as just C, C++ and then stage2 onwards as "all".
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 --- Comment #4 from Dennis Clarke --- elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2: Section Header[37]: sh_name: .debug_info sh_addr: 0 sh_flags: 0 sh_size: 0x1636a2sh_type:[ SHT_PROGBITS ] sh_offset:0x1faa0 sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 Whereas stage3 reports : Section Header[37]: sh_name: .debug_info sh_addr: 0 sh_flags: 0 sh_size: 0x163698sh_type:[ SHT_PROGBITS ] sh_offset:0x1faa0 sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 Not exactly 8 bytes. Looks like 10 bytes diff. All other "sh_size" section size data matches. The output from elfdump is 75k lines long with 1134 lines of diff : d$ elfdump ./stage3-gcc/go/parse.o > /tmp/go_parse_elfdump.3 d$ elfdump ./stage2-gcc/go/parse.o > /tmp/go_parse_elfdump.2 d$ wc -l /tmp/go_parse_elfdump.3 75428 /tmp/go_parse_elfdump.3 d$ wc -l /tmp/go_parse_elfdump.2 75428 /tmp/go_parse_elfdump.2 d$ diff /tmp/go_parse_elfdump.2 /tmp/go_parse_elfdump.3 | wc -l 1134
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #3 from Eric Botcazou ---
> the ELF section header table seems
> to be in a slightly different place between the two files :
>
> d$ elfdump -delv stage2-gcc/go/parse.o
>
> ELF Header
> ei_magic: { 0x7f, E, L, F }
> ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
> ei_osabi: ELFOSABI_NONE ei_abiversion: 0
> e_machine: EM_SPARCV9 e_version: EV_CURRENT
> e_type: ET_REL
> e_flags:[ EF_SPARCV9_TSO ]
> e_entry: 0 e_ehsize: 64 e_shstrndx: 1
> e_shoff: 0x3b7cd8 e_shentsize: 64 e_shnum: 86
> e_phoff: 0 e_phentsize: 0 e_phnum: 0
>
> d$ elfdump -delv stage3-gcc/go/parse.o
>
> ELF Header
> ei_magic: { 0x7f, E, L, F }
> ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
> ei_osabi: ELFOSABI_NONE ei_abiversion: 0
> e_machine: EM_SPARCV9 e_version: EV_CURRENT
> e_type: ET_REL
> e_flags:[ EF_SPARCV9_TSO ]
> e_entry: 0 e_ehsize: 64 e_shstrndx: 1
> e_shoff: 0x3b7cd0 e_shentsize: 64 e_shnum: 86
> e_phoff: 0 e_phentsize: 0 e_phnum: 0
> d$
>
> So there I see 0x3b7cd8 in stage2 and 0x3b7cd0 in stage3.
Sure, but we need to find where this difference comes from, i.e. which section
of the executable has a different size. elfdump can probably dump this info.
> At first glance there appears to be only an 8 byte difference in the
> size of the file but looking down through the various sections in the
> ELF data for both files I see the same data represented in very similar
> places but yet, slightly different. For example the ELF header offset
> is 0x3b7cd0 in one of them and 0x3b7cd8 in the other. Is this a valid
> functional difference at all?
Maybe not, but the comparison process is very strict. In any case, 2 identical
compilers should produce identical object files (modulo timestamp).
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926
--- Comment #2 from Dennis Clarke ---
the ELF section header table seems
to be in a slightly different place between the two files :
d$ elfdump -delv stage2-gcc/go/parse.o
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_NONE ei_abiversion: 0
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_REL
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0 e_ehsize: 64 e_shstrndx: 1
e_shoff: 0x3b7cd8 e_shentsize: 64 e_shnum: 86
e_phoff: 0 e_phentsize: 0 e_phnum: 0
d$ elfdump -delv stage3-gcc/go/parse.o
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_NONE ei_abiversion: 0
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_REL
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0 e_ehsize: 64 e_shstrndx: 1
e_shoff: 0x3b7cd0 e_shentsize: 64 e_shnum: 86
e_phoff: 0 e_phentsize: 0 e_phnum: 0
d$
So there I see 0x3b7cd8 in stage2 and 0x3b7cd0 in stage3.
At first glance there appears to be only an 8 byte difference in the
size of the file but looking down through the various sections in the
ELF data for both files I see the same data represented in very similar
places but yet, slightly different. For example the ELF header offset
is 0x3b7cd0 in one of them and 0x3b7cd8 in the other. Is this a valid
functional difference at all? Perhaps a bug lay inside the linker which
created the actual object file? Looking at both files and the ELF data
between them I see the exact same data in both and yet in different
addresses :
stage 2 :
Section Header[44]: sh_name: .bss
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204458sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
stage 3 :
Section Header[44]: sh_name: .bss
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204450sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
That sort of difference lay between the two files in many many places.
Slightly different by 8 bytes again however nm tells me that the symbol
listing is identical between the two files. Perhaps there is no actual
"functional" difference between the files at all.
[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81926 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-22 CC||ebotcazou at gcc dot gnu.org, ||ro at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > The compiler to be used for the initial stage of bootstrap is gcc 6.4.0 thus > : > > d$ /usr/local/gcc6/bin/gcc --version > gcc (genunix Wed Jul 26 02:41:24 GMT 2017) 6.4.0 > Copyright (C) 2017 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > That had reasonable test results previously : > https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg02881.html But Go wasn't enabled for it, was it? > There seems to be only an 8 byte size difference : > > d$ ls -lo ./stage2-gcc/go/parse.o ./stage3-gcc/go/parse.o > -rw-r--r-- 1 dclarke 3904088 Aug 22 04:00 ./stage2-gcc/go/parse.o > -rw-r--r-- 1 dclarke 3904080 Aug 22 04:57 ./stage3-gcc/go/parse.o > > Also the various symbols in these object files are identical but the > location of data inside the ELF files is slightly different : Can you find out (with objdump for example) which section differs in size? Rainer, do you test Go in this configuration (system as + ld)?
