Tripe test failure update

"Nils M Holm" <nmh@t3x.org>
Sun, 4 May 2014 10:53:29 +0200

          From comp.compilers

Related articles
Mysterious triple test failures nmh@t3x.org (Nils M Holm) (2014-05-03)
Re: Mysterious triple test failures kaz@kylheku.com (Kaz Kylheku) (2014-05-03)
Tripe test failure update nmh@t3x.org (Nils M Holm) (2014-05-04)
Re: Tripe test failure update nmh@t3x.org (Nils M Holm) (2014-05-05)
Re: Triple test failure update cdodd@acm.org (Chris Dodd) (2014-05-23)
Re: Triple test failure update nmh@t3x.org (Nils M Holm) (2014-05-23)
Re: Triple test failure update alexfrunews@gmail.com (2014-05-23)
| List of all articles for this month |

From: "Nils M Holm" <nmh@t3x.org>
Newsgroups: comp.compilers
Date: Sun, 4 May 2014 10:53:29 +0200
Organization: Compilers Central
References: 14-05-003 14-05-004
Keywords: debug, comment
Posted-Date: 04 May 2014 15:32:48 EDT

I am currently running the following procedure to find out at which
point the triple test of my SubC compiler fails. This is what happens:


The stage-0 (third-party-compiled) scc0 is used to generate a stage-1
scc1. Then scc1 is used to generate the stage-2 compiler scc2.


Then scc1 compiles itself to 1) assembly 2) a binary. The same is done
with scc2.


The assembly output of scc1 and scc2 is identical, the binaries are not.
*Both* compilers seem to work perfectly fine.


The assembler and linker of the Linux system are used to generate
binaries from the assembly output.


Adding a stage-3 compiler (compiled with scc2) and comparing against
scc2 does not change anything: same assembly, different executables.


The test as described above works (identical binaries) on FreeBSD/386,
FreeBSD/x86-64, FreeBSD/ARM, NetBSD-x86-64, DOS-8086, and others.


It sometimes fails (maybe depending on version?) on Linux-x86-64.
(OpenBSD/386 was a false negative.)


Differences in the file are literally all over the place. A diff on
the hexdumps reports multiple thousand differences).


All differences I have found so far are related to addresses, like in
the following disassembly snippet:


SCC
00000353 74 02 jz 0x00000357
00000355 EB 16 ljmp 0x0000036D
00000357 E8 AD F6 00 00 lcall 0x0000FA09 *****
0000035C 48 dec %eax
0000035D 89 04 25 38 96 61 00 movl %eax, 0x619638(,1)
------------------------------------------------------------------
SCC1
00000353 74 02 jz 0x00000357
00000355 EB 16 ljmp 0x0000036D
00000357 E8 47 F6 00 00 lcall 0x0000F9A3 *****
0000035C 48 dec %eax
0000035D 89 04 25 38 96 61 00 movl %eax, 0x619638(,1)


I would say that the cause for the difference is in the assembler
or linker, but I would like to understand what is going on here.


John wrote:
[Are the stage-0 and stage-1 assembly sources the same? The
first thing that occurs to me is that the code is laid out
differently so the variable-length branch logic has long
and short instructions in different places. -John]


Yes, the stages 0 and 1 generate identical assembly output,
so any change in the layout would have to happen in later
phases (i.e. assembly and linking). How can that happen?


--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
[When you compared the individual object files that the assembler
genereated, what did you find? -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.