Reproducibility terminology/definitions
Pol Dellaiera
pol.dellaiera at gmail.com
Thu Nov 9 10:28:19 UTC 2023
Thanks John,
I will read all of this carefully.
In the meantime, and based on all the input I gathered, I have begun drafting a document which is now available at: https://typst.app/project/rhUl4XwrXToXvxjoaWB6DI
The idea is to have a more formal approach of the definitions.
Let me know what you think, feel free to made all your comments.
On 11/9/23 01:31, John Gilmore wrote:
> Pol Dellaiera <pol.dellaiera at gmail.com> wrote:
>> To that end, I'm currently drafting a formal definition of
>> reproducibility that I hope to contribute. However, before I proceed
>> further, I would like to know whether any of you have already worked
>> on formulating such a definition.
>
> Here are a few emails (from prior R-B discussions) that go into how
> "reproducibility" might be formally defined and verified. I'm sure
> that many other inputs would also be useful; these are just two that
> I could recall and easily find.
>
> The final series of emails below describes how Cygnus made the GNU
> cross-compiler tools "reproducible" in the early 1990s -- in the sense
> that if you cross-compiled the same source code on any of 9 hosting
> platforms, the tools would produce the exact bit-for-bit identical
> binaries for the target platform. (E.g. a Mac, a Windows machine, and a
> SPARC Solaris machine were verified to cross-compile the "GNU make"
> source code into an identical "gmake" binary, that was targeted to run
> on a Motorola 68000 running SunOS.) This reproducibility also included
> being able to cross-build identical binaries for all the GNU compiler
> tools themselves (as well as for all of our hundreds of compiler test
> cases). The several man-years of engineering required to stamp out all
> the bugs that made the compilers not reproducible, was a prerequisite to
> today's efforts to make whole linux distributions (that are compiled by
> those GNU tools) reproducible.
>
> John
>
> To: General discussions about reproducible builds
> <rb-general at lists.reproducible-builds.org>
> References: <CAAS6=7giX-z416wJOFebfViMMXoiTSCuOFw+iHXCCm9itFmO2A at mail.gmail.com>
> <87sgxgok9k.fsf at gnu.org>
> Comments: In-reply-to =?us-ascii?Q?=3D=3Futf-8=3FQ=3FLudovic=5FCourt=3DC3?=
> =?us-ascii?Q?=3DA8s=3F=3D?= <ludo at gnu.org>
> message dated "Fri, 25 Jan 2019 15:59:51 +0100."
> MIME-Version: 1.0
> Date: Mon, 28 Jan 2019 23:18:43 -0800
> Message-ID: <15495.1548746323 at hop.toad.com>
> From: John Gilmore <gnu at toad.com>
> Subject: Re: [rb-general] Definition of "reproducible build"
> Content-Type: multipart/mixed; boundary="===============0660915116=="
> Errors-To: rb-general-bounces+gnu=toad.com at lists.reproducible-builds.org
> Sender: "rb-general"
> <rb-general-bounces+gnu=toad.com at lists.reproducible-builds.org>
>
> --===============0660915116==
> Content-Type: text/plain
> Content-Transfer-Encoding: 8bit
>
> =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo at gnu.org> wrote:
>> I agree that insisting on provenance is crucial. Dockerfiles (andsimilar) are often viewed as “source”, but they really aren’t source:the actual source would come with the distros they refer to (Debian,pip, etc.)
>> Those distros might in turn refer to external pre-built binaries,though, such as “bootstrap binaries” for compilers (Rust, OpenJDK, andso on.)
>
> I propose a definition for whether a bootable OS distro is reproducible.
> (If what you're building is not a whole distro that can self-compile,
> this definition doesn't apply.)
>
> Our initial goal would be to produce a bootable binary release (DVD or
> USB stick) and a source release (ditto). The source release would
> include the script that allows the binary release to recompile the
> source release to a new binary release that ends up bit-for-bit
> identical. Such a binary/source release pair would be called
> "reproducible".
>
> That's useful: If you have to fix a bug in it, you can make the mods you
> need in the source tree, rebuild the world, and out will come a release
> with just that one change in the binaries, verifiably identical except
> where it matters. And developers can use such a release to detect what
> changes matter to whom, such as: when you alter a system include file,
> which binaries change?
>
> During development, the code would be built by some earlier release's
> tools, built piecemeal, etc, like current build processes do. Anytime
> before release, the developers can test whether a draft source release
> builds into a binary release that itself can build the sources into the
> same binary release. And fix any discrepancies, ideally long before
> release.
>
> This is similar to what GCC does to test itself, or what Cygnus did to
> test the whole toolchain for cross-compiling. But applied to the
> entire OS release.
>
> Such a paired source/binary release doesn't require a chain of
> provenance of earlier binary software, particularly if people can
> demonstrate bootstrapping it using several different earlier compiler
> toolchains, still producing the same binaries. You can bootstrap
> it with itself.
>
> The separate efforts to minimize the amount of binary code we have to
> trust to do a rebuild are laudable and fascinating. Keep going! But we
> shouldn't require whole distros to do that yet. We haven't even
> accomplished a basic paired binary/source reproducible release yet, for
> any major release -- or have we?
>
> John
>
> PS: For extra points, the binary release should be able to cross-compile
> its source release into a binary release for each other supported
> platform, reproducibly. And those other-platform binary releases should
> cross-compile the source release back bit-for-bit into the same binary
> release you started with.
>
>
>
> To: General discussions about reproducible builds
> <rb-general at lists.reproducible-builds.org>
> Comments: In-reply-to Holger Levsen <holger at layer-acht.org>
> message dated "Thu, 14 Feb 2019 12:54:58 +0000."
> Date: Thu, 14 Feb 2019 12:25:24 -0800
> From: John Gilmore <gnu at toad.com>
> Subject: Re: [rb-general] Definition of "reproducible build"
>
>> I like the idea, however what you are proposing is basically a new
>> distro/fork, where you would remove all unreproducible packages, as
>> every distro still has some unreproducible bits.
>
> I suggest going the other way -- produce a distro that is "80%
> reproducible" from its source code USB stick and its binary boot USB
> stick. You'd already have the global reproducibility structure and
> scripts written and working, even before the last packages are
> individually reproducible. That global reproducibility tech would be
> immediately adoptable by any distro. The output of the reproduction
> scripts would be a bootable binary that does boot and run! It would
> still have differences from the "release master" bootable binary, but
> those differences would be irrelevant to the functioning of the binary,
> and would be clearly visible with "diff -r".
>
> (For one thing, this would cause the distros to actually produce a
> "source code USB stick image". Currently most of them don't. They
> instead require you to download thousands of separate source packages or
> tarballs, and have no scripts readily visible for building those into a
> bootable binary image.)
>
> After accomplishing that, then the focus could go on the 20% (or 10% or
> whatever) of packages that aren't yet reproducible. And, people making
> small distros could cut out such packages to make a 100% reproducible
> distro, as Holger suggested.
>
> John
>
>
>
> To: James Addison <jay at jp-hosting.net>
> cc: John Gilmore <gnu at toad.com>,
> General discussions about reproducible builds <rb-general at lists.reproducible-builds.org>,
> Holger Levsen <holger at layer-acht.org>
> Subject: Re: Sphinx: localisation changes / reproducibility
> In-reply-to: <CALDQ5NyqMPafZ+JU9t=A+EzV2BeKw-dLbcsV_QG_=X1trES7gQ at mail.gmail.com>
> References: <CALDQ5NxdxaNURUKd8uoEeH+FPQdtHX-XAYzNYCO-cjZLFOeSUg at mail.gmail.com> <CALDQ5Nzxh9hUUd2GG1pEf7d=5KEiPMWoYMzZNsKQvvZOXvgnrA at mail.gmail.com> <ZDmgonrRP2EuUHtY at layer-acht.org> <CALDQ5NxXW+oPFdFAA_AZqzr97FbumUb+vy3B7kb4vqyHTwnXtA at mail.gmail.com> <5630.1681601150 at hop.toad.com> <CALDQ5NyqMPafZ+JU9t=A+EzV2BeKw-dLbcsV_QG_=X1trES7gQ at mail.gmail.com>
> Comments: In-reply-to James Addison <jay at jp-hosting.net>
> message dated "Tue, 18 Apr 2023 00:08:32 +0100."
> Date: Mon, 17 Apr 2023 20:54:39 -0700
> Message-ID: <14102.1681790079 at hop.toad.com>
> From: John Gilmore <gnu at toad.com>
>
> James Addison <jay at jp-hosting.net> wrote:
>> When the goal is to build the software as it was available to the
>> author at the time of code commit/check-in - and I think that that is
>> a valid use case - then that makes sense.
>
> I think of the goal as being less related to the author, and more
> related to the creator of a widespread binary release (such as a Linux
> distribution, or an app that goes into an app-store).
>
> The goal is then that the recipient of that binary release can verify
> that the source code they obtained from the same place is able to
> rebuild that exact widespread binary release. This proves that the
> source code can be trusted for some purposes, such as being used to read
> it to understand what the binary does. Or to make small bug-fixes to it.
> Or to become the base for further evolution of the project if the
> maintainer is suddenly "hit by a bus" and stops making further releases.
>
> James Addison <jay at jp-hosting.net> wrote:
>> Inverting the question somewhat: if a single source-base is rebuilt
>> using two different SOURCE_DATE_EPOCH values (let's say, 1970-01-01
>> and 2023-04-18), then what are expected/valid differences in the
>> resulting output?
>
> In the ideal circumstances, the resulting output would be identical,
> because the build process would have no dependencies on
> SOURCE_DATE_EPOCH. In these ideal circumstances, the code is "portable",
> in the same sense that people understand "portable" code will build and
> run the same on an ARM running MacOS as it does on an x86 running
> Windows. There are many ways to make code portable, but the most robust
> of them is to *eliminate* dependencies.
>
> A more fragile way would be to #ifdef your code to adjust for every
> supported build or run environment. That fragile way breaks as soon as
> it needs to build or run in a new environment, whereas the robust way
> has already made it likely to "just work" in a new environment that it
> has never encountered before (or to have only one or two minor things
> that need adjusting). Note that if it built fine in a Linux system
> version X, then a later Linux system version Y is a "new environment"
> and might break the code. The robust version is again less likely to
> break, because it inherently, by design, cares less about the nitty
> gritty details of its environment.
>
> Much code in Linux does not reach that ideal (yet!). Instead, builds of
> non-ideal code use SOURCE_DATE_EPOCH as a crutch to limit their
> dependencies on the local build environment, replacing those
> dependencies with a dependency on SOURCE_DATE_EPOCH.
>
> So, if you rebuild a non-ideal package with two different values of
> SOURCE_DATE_EPOCH, you will get two different binaries that differ in
> the areas of dependency. For example, if the documentation embeds a
> build-date in its page footer, you'd expect every page of the built
> documentation would differ. If the "--version" output of the program
> embeds the build date, then the code that produces that output would
> differ. Etc. In fact, "fuzzing" their code with different values
> of SOURCE_DATE_EPOCH can help a maintainer identify where those
> dependencies still remain.
>
> We try to talk package authors out of such dependencies, but ultimately
> it's their package and they make the architectural decisions. To some
> of them it's incredibly important that the build date appears in the
> man-page. Reproducibility usually features lower among their priorities
> than it does in ours.
>
> John
>
>
>
> Message-Id: <201701240247.v0O2lZXw022950 at new.toad.com>
> To: General discussions about reproducible builds <rb-general at lists.reproducible-builds.org>,
> gnu at toad.com
> Subject: Re: [rb-general] SOURCE_PREFIX_MAP and Occam's Razor
> In-reply-to: <8e8020ae-017e-b523-f7f0-f372c6576c95 at debian.org>
> References: <cee56eda-b5da-0348-f639-ced388444515 at debian.org> <20170112053602.GA16366 at fujitsu.shahaf.local2> <1271f81a-eb2b-a2ef-e275-7992a4051892 at debian.org> <20170113034502.GA1356 at fujitsu.shahaf.local2> <87bmvapunh.fsf at alice.fifthhorseman.net> <5aef51ca-d2af-8b9e-17c1-7e157e7b0361 at debian.org> <877f5xo7bz.fsf at alice.fifthhorseman.net> <20170115000630.GA13098 at layer-acht.org> <201701160355.v0G3tiXw032083 at new.toad.com> <4ddff3f6-6953-9a3f-ce6b-b5dc08c270b9 at debian.org> <201701220331.v0M3VlXw002327 at new.toad.com> <8e8020ae-017e-b523-f7f0-f372c6576c95 at debian.org>
> Comments: In-reply-to Ximin Luo <infinity0 at debian.org>
> message dated "Sun, 22 Jan 2017 10:03:00 +0000."
> Date: Mon, 23 Jan 2017 18:47:35 -0800
> From: John Gilmore <gnu at toad.com>
>
>> talk is cheap, show me the code
>
> Arrogance is often a useful attitude for a young person, but it's
> useful to first determine whether one is in the wrong. When working
> on code that's decades old, reading ChangeLog files is often
> educational.
>
>>> At Cygnus in the 1990s we made the GNU tools fully reproducible, even
>>> for cross-compilation. This required dealing with many byte-order
>>> issues and floating-point representations and such -- a set of issues
>>> that you don't have. We built the byte-order-independent BFD tools,
>>> and the new GNU linker, pretty much from scratch, for just that purpose.
>
> Ximin Luo said:
>> Do you have this documented in detail somewhere? There is a difference
>> between 100% reproducible and 92% reproducible. We are covering the
>> final few %, so forgive me that I am not interested in people who
>> claim their stuff is "reproducible" but actually do need things like
>> SOURCE_DATE_EPOCH in corner cases that they didn't think about because
>> they were too busy telling everyone how they set timestamps to 0
>> everywhere.
>
> I thank you for covering the final few %. It is important work that
> needs to be done.
>
> We did not make every program in the universe reproducible. We made
> the GNU tools that we were shipping and supporting -- and all of our
> test cases compiled by them -- reproducible. That includes gcc, gdb,
> gas, binutils, gnu make, and a few other things. Plus several hundred
> compiler test cases. We didn't even have any Linux systems then
> (Yggdrasil, the first distro, had its first release in late 1992;
> Debian had just started in late 1993); we and all of our customers
> were running on proprietary Unix and MSDOS machines. See:
>
> "The Daemon, the GNU and the Penguin" by Peter Salus
> http://www.groklaw.net/articlebasic.php?story=20051031235811490
>
> What we did is documented in the code. I've done some poking around
> in early documentation, and it's interesting that I haven't found any
> place yet where we specifically and publicly said we made the output
> files fully determined by the source files. We just treated it as a
> bug, and fixed it, anytime the object files didn't match bit-for-bit.
> It wasn't something to shout about, it was just good engineering.
>
> Originally the GNU tools only worked native; we improved 'em. I made
> the first GCC cross-compiler in about March 1990, but it was a
> one-shot release for a single customer. We made six or eight of those
> one-shots for various platforms. It got hard to support each customer
> out of a unique source tree, so we invested the time to make the whole
> thing configurable in one tree. Cygnus was the first to build and
> ship and support a suite of GNU cross-compilers, from a single source
> tree, in October 1992. These did have object-file differences in the
> timestamps, and in some floating point constants, i.e. they weren't
> fully deterministic, but the cross-compiler bear was finally starting
> to dance.
>
> Nine months later, we shipped our fourth major multi-platform
> supported GNU compiler release (93q2) in June 1993. Compiling the
> same source files on 8 of the 9 different host systems, for the
> Motorola 68000 target (among 10 target environments using 5 different
> CPU chips), produced exactly bit-for-bit identical object files. Part
> of making this happen was by adding a "-gnodir" switch to gcc that
> suppressed the directory from the debug information. (RMS, who was
> maintaining GCC at the time, suggested merely dropping the directory
> name in all cases. We left that issue unresolved pending a later
> merge with his version of the code.)
>
> The only difference between the files produced on different platforms
> was a minor "release notes" issue about excess precision in floating
> point numbers when cross-compiling from the 9th host platform, the IBM
> RS/6000 (see below; it got resolved in later releases). We verified
> this with the DejaGnu test framework, which we designed and built as
> part of this effort. Just to get the GNU tools to build cleanly on
> all those platforms, and to test them in both native UNIX and MSDOS
> systems, and in embedded boards without an operating system, took a
> team of 6 or 8 talented people many months. We had to design and
> build the first "configure" script, also. (My apologies to everyone
> for how complicated autoconf has become in the intervening 25 years).
> Emails documenting some of this are below.
>
> I have a copy of the GNU binutils-2.18.tar.bz2 from 2007. In the file
> binutils-2.18/bfd/ChangeLog-9193 is this entry:
>
> Wed Oct 28 13:42:09 1992 John Gilmore (gnu at cygnus.com)
>
> * coffcode.h (coff_write_object_contents): Zero timestamp field.
>
> One of the emails below (by Ian Lance Taylor) suggests searching in
> bfd/coffcode.h for the string "timestamp". There you will see:
>
> /* We will NOT put a fucking timestamp in the header here. Every time you
> put it back, I will come in and take it out again. I'm sorry. This
> field does not belong here. We fill it with a 0 so it compares the
> same but is not a reasonable time. -- gnu at cygnus.com */
> internal_f.f_timdat = 0;
>
> The comment was addressed to Steve Chamberlain, a great and prolific
> Cygnus programmer who was the original author of the BFD library.
> Note that this code only applied to the COFF object file format. A
> similar change was made for ECOFF. There is similar code in bfd/som.c
> for the HP PA-RISC SOM file format, setting timestamps to zero.
>
> That code and ChangeLog entries have survived right up through the
> current binutils release, binutils-2.27 from 2016. In that code you
> will also see Chris Demetriou's 2009 changes for
> BFD_DETERMINISTIC_OUTPUT in archive (ar(1)) files, which avoid putting
> each file's uid, gid, and timestamps in object file archives. (This
> is now the compiled default in ubuntu-16.04, though it wasn't default
> in ubuntu-14.04. Back in 1992 we needed those archive timestamps for
> compatability with Sun's and BSD's proprietary UNIX linker.)
>
> The closest thing to a published, broad summary of what we were doing
> back in 1992 and 1993 is from _Inside Cygnus Engineering_ issues
> 1992-09 and 1992-12. In general see:
>
> http://www.toad.com/gnu/cygnus/
>
> http://www.toad.com/gnu/cygnus/ice/ice-1992-09.txt
>
> PRODUCTS AND RELEASES
> ---------------------
>
> 1. Progressive Update
>
> We are still hard at work on the next progressive release. In the
> process, we have done significant cleanup and reorganization of the
> libraries (libgcc, libc and libm, libiberty, libg++) to make the
> toolchain easily configurable for many cross-development platforms.
> Our test framework has been ported and enhanced to increase
> platform-independence of test cases, particularly for cross development.
> And then there has been the very large task of building and testing
> each platform, fixing bugs, and starting the cycle again.
>
> As expected, logistics is proving to be the greatest challenge.
> Although we have built and verified most of the platforms below at one
> time or another in engineering, getting all of them into product boxes
> has proved to be our undoing. We will not be able to final- and
> installation-test all of these in a timely fashion. Thus we have decided
> to delay the final ship date and decrease the number of platforms that we
> will package and put on the shelf.
>
> The original ship date was set for September 30. We are moving this
> back a month to October 31. Core and Leveraged customers who needs
> updates at the end of the month will receive a beta tape and documentation.
> If you need an update, please contact us (at engnews at cygnus.com) as soon
> as possible. We anticipate that the only difference betweeb such a taoe
> and the stock tapes will be in the installation procedure, although,
> of course, late-breaking bugs may be discovered. We apologize for the
> inconvenience this causes.
>
> Our matrix of supported platforms covers both the needs of our current
> customers and inputs from our sales and marketing groups. To reduce
> the number of 'stock' platforms, we've decided to support certain
> platforms on a custom basis only. Stock platforms are shown with X's
> in the table below. Platforms that we will not productize are shown with
> O's. If there is sufficient customer interest in any of these, we will
> make a prerelease tape available, or make it a stock item for the
> Q4 progressive release.
>
>
> \ HOST | DEC IBM SGI
> TARGET \ | SUN3 SUN4 SOL2 STN RS6K IRIS DOS HP300 HP700
> --------------+--------------------------------------------------------
> Native | X X X X X X
> 68k VxWorks | X X X X X X X
> 68k a.out | X X X X X
> 68k coff | X O O
> 29k UDI | X X
> ix86 a.out | X O O
> i960 VxWorks | O O X O
> i960 Nindy | O O
> SPARC VxWorks | X
> SPARC a.out | O
>
> X = on the shelf
> O = may be custom built
> 68k = 68000, 68010, 68020, 68030, 68040
> ix86 = 386, 486
> i960 = KA, KB, CA
> SPARC = SPARC, SPARClite
>
> [End of excerpt from Inside Cygnus Engineering; you can read many more
> issues of it at the above URLs.]
>
> We shipped that "P3" progressive release in October 1992. Then we
> released a stability update in December, and further updates every
> three months for years thereafter. The 93Q2 release of June 1993 is
> the first release in which we made the results bit-for-bit identical
> on all platforms except the RS/6000. That is documented in the emails
> below. Note the progression of dates.
>
> John
>
> Date: Sun, 11 Oct 92 18:27:12 PDT
> From: david d `zoo' zuhn <zoo at cygnus.com>
> Organization: Cygnus Support -- +1 415 322 3816
> To: p3
> Subject: comparison results on p3 testing (GNBN)
>
> [ After losing an hour of testing, I realized that -gnodir was required for
> this exercise. Sigh. ]
>
> Good news on this front.
>
> With the exception of m68k-coff targets, all hosts generate identical
> object files for the test case of GNU hello v1.1. The m68k-coff objects
> appear to be different, beyond the timestamp (which also appears to be
> different, in byte 8, right?). I don't know enough about coff or object
> files in general to try to find the differences.
>
> These objects all live in ~zoo/testing/{host}-{target}-objdir, in case some
> enterprising hacker wishes to bang on this problem.
>
> For some bad news, the final executable for m68k-aout targets is different
> for each host:
>
> -rwxrwxr-x 1 zoo 146247 Oct 11 17:58 hppa1.1-hp-hpux-m68k-aout-objdir/hello
> -rwxrwxr-x 1 zoo 146315 Oct 11 18:03 mips-dec-ultrix-m68k-aout-objdir/hello
> -rwxrwxr-x 1 zoo 146348 Oct 11 18:01 rs6000-ibm-aix-m68k-aout-objdir/hello
> -rwxrwxr-x 1 zoo 146484 Oct 11 18:00 sparc-sun-sunos411-m68k-aout-objdir/hello
>
> This is the only toolchain that is built on several hosts that is complete
> (vxworks toolchains don't produce executables). Well, okay, we built
> m68k-coff for a couple of hosts, and those don't compare identically
> either, but that shouldn't be a surprise.
>
>
> From: ian at cygnus.com (Ian Lance Taylor)
> Date: Mon, 12 Oct 92 19:15:19 EDT
> To: zoo at cygnus.com
> Cc: ian at cygnus.com, p3 at cygnus.com
> Subject: comparison results on p3 testing (GNBN)
>
> Date: Sun, 11 Oct 92 18:27:12 PDT
> From: david d `zoo' zuhn <zoo at cygnus.com>
>
> With the exception of m68k-coff targets, all hosts generate identical
> object files for the test case of GNU hello v1.1. The m68k-coff objects
> appear to be different, beyond the timestamp (which also appears to be
> different, in byte 8, right?). I don't know enough about coff or object
> files in general to try to find the differences.
>
> Well, after considerable tedium I tracked down the first of five
> differences between the files created by mips-dec-ultrix and by
> sparc-sun-sunos411. The coff_swap_aux_out function only sets the
> first eight or so bytes of the outgoing auxent for the C_FILE case, so
> the remaining bytes are random garbage. Perhaps a bzero at the start
> of coff_swap_aux_out in coffcode.h would be appropriate. I'm leaving
> now, though.
>
> Ian
>
>
> Date: Tue, 13 Oct 92 11:33:36 PDT
> From: david d `zoo' zuhn <zoo at cygnus.com>
> Organization: Cygnus Support -- +1 415 322 3816
> To: ian at cygnus.com (Ian Lance Taylor)
> Cc: p3
> Subject: comparison results on p3 testing (GNBN)
>
> I think the intention in our tools is to not have the time stamp differ.
> I'm not certain of this though.... anyone else?
>
>
> To: david d `zoo' zuhn <zoo at cygnus.com>
> Cc: ian at cygnus.com (Ian Lance Taylor), p3
> Subject: Re: comparison results on p3 testing (GNBN)
> Date: Tue, 13 Oct 92 11:56:10 -0700
> From: gnu at cygnus.com
>
>> I think the intention in our tools is to not have the time stamp differ.
>> I'm not certain of this though.... anyone else?
>
> I strongly agree that our object files should not contain timestamps.
> If you compile the same sources with the same compiler, you should get
> the same result -- down to the bit.
>
> John
>
>
> From: ian at cygnus.com (Ian Lance Taylor)
> Date: Wed, 28 Oct 92 13:40:40 EST
> To: gumby at cygnus.com
> Subject: -gnodir
> Cc: p3 at cygnus.com, ian at cygnus.com
>
> The -gnodir hack I put into p3 gcc just removes the current directory
> name. If the file name is passed to gcc with directories, then those
> do appear in the debugging file. For example, gcc -gnodir
> /foo/bar/file.c will put /foo/bar/file.c in the debugging information.
> This turns out not to matter for p3, so far as I can tell, because the
> only times pathnames are given to gcc they are always of the form
> ../p3/foo.
>
> Do you think I should improve it to use the basename of the argument,
> or do you think that since this is just an undocumented hack anyhow
> there's no point?
>
> Ian
>
>
> To: ian at cygnus.com (Ian Lance Taylor)
> Cc: gumby at cygnus.com, p3 at cygnus.com, gnu
> Subject: Re: -gnodir
> Date: Wed, 28 Oct 92 13:09:17 -0800
> From: gnu at cygnus.com
>
>> Do you think I should improve it to use the basename of the argument,
>> or do you think that since this is just an undocumented hack anyhow
>> there's no point?
>
> I do not think that this should be changed. If the user passes in an
> absolute pathname, they should get what they get. Cutting it down to
> the basename would be the wrong thing; it would not enable the
> debugger to tell the difference between ../bfd/core.c and
> ../gdb/core.c, for example.
>
> I think that -gnodir should become a supported feature, but we should get
> some further experience with it, first. Did it accomplish its intended
> purpose of making it possible to compare all the P3 .o's easily?
>
> John
>
> Date: Wed, 28 Oct 92 13:20:19 PST
> From: david d `zoo' zuhn <zoo at cygnus.com>
> Organization: Cygnus Support -- +1 415 322 3858
> To: gnu at cygnus.com
> Cc: p3
> Subject: Re: -gnodir
>
> I think that -gnodir should become a supported feature, but we should get
> some further experience with it, first. Did it accomplish its intended
> purpose of making it possible to compare all the P3 .o's easily?
>
> Yes, it did help here, quite a bit.
>
>
> From: ian at cygnus.com (Ian Lance Taylor)
> Date: Wed, 28 Oct 92 16:27:47 EST
> To: gnu at cygnus.com
> Cc: gumby at cygnus.com, p3 at cygnus.com, ian at cygnus.com
> Subject: -gnodir
>
> Date: Wed, 28 Oct 92 13:09:17 -0800
> From: gnu at cygnus.com
>
> I think that -gnodir should become a supported feature, but we should get
> some further experience with it, first. Did it accomplish its intended
> purpose of making it possible to compare all the P3 .o's easily?
>
> Yes, it did. I did not an exhaustive comparison of everything (too
> much other stuff to do, but this should definitely be done for p4).
> For the ones that I did compare the only differences were the floating
> point differences and the COFF timestamps.
>
> In the collection of mail you sent me, rms suggested never generating
> the directory name at all instead of adding the -gnodir option. I'm
> not sure I know how to find out whether that would ever cause any
> problems. dbx on the Sun4 seems to be able to cope.
>
> We could resolve the floating point differences by making gcc use the
> newlib atof, as you suggested. [copyright discussion elided...--gnu]
> Not a problem for us, but this would seem to be an obstacle to getting
> the modification accepted by the FSF. I don't know if rms has any
> opinions on the issue.
>
> As far as the COFF timestamps go, yes, we are still generating them.
> Take a look at the comment in bfd/coffcode.h (search for the string
> "timestamp") and argue it with Steve.
>
> Ian
>
>
> To: wilson, zoo, progressive
> Subject: Stage2/3 differences in gdb caused by stage1/2 diff in libgcc2
> Date: Tue, 06 Apr 93 23:58:22 -0700
> From: gnu at cygnus.com
>
> In comparing the directories built in stage 2 and 3 of a Progressive
> build, in /cygint/gnu/cdware/sparc-sun-sunos4.1.1-objdir.[23], I found
> that the GDB binary differed. The difference comes from a module in
> libgcc2.a in the previous stage [objdir.1 and objdir.2], which is linked
> in to the GDB binary by the previous stage's compiler.
>
> Note that the libgcc2.a in stage 1 is built with the freshly built
> stage1 gcc, so it should produce identical executables to the stage2
> gcc.
>
> The difference is that the debug symbol for __gnuc_va_list:t21=*2
> occurs in stage2, but not in stage1. This happens in both _eprintf.o
> and _new_handler.o in the built gcc/libgcc2 directories.
>
> I don't have time to chase this further (CDware release to cut), but I
> thought you-all should know. My guess is there's still some
> misadventures in the Makefile regarding include file paths while
> building libgcc2.
>
> John
>
> PS: The stage2/3 comparisons in test-build.mk do not catch this,
> because they only compare the .o files. The difference occurs only
> in the linked executables (at the stage2/3 level). *All* files
> need to be compared, not just .o files, and all bytes of these files
> need comparing; the first 10 bytes can't be ignored.
>
>
> From: cassidy (Jeffrey Wheat)
> Subject: q2 testing
> To: progressive, testing
> Date: Thu, 24 Jun 1993 21:38:57 -0700 (PDT)
>
> Hi
>
> I've completed testing for the m68k-aout cross targets. The systems
> that I tested on are: solaris, sun3, sun4, decstation, rs6000, hp300 and 700.
> I was unable to test on the sco box (no account there), and the sgi (no gcc).
>
> The only problem I encountered, was a big difference in the code that was
> generated by the rs6000. All other hosts generated identical code. The test
> in question is the gcc.execute/920715-1.c test. The diff's between the srec
> output are:
>
> [pluto] [gcc/rs6000-ibm-aix3.2] % diff 920715-1 ../mips-dec-ultrix/920715-1
> 1112,1115c1112,1115
> < S31A0000510EA94A5135F294001AF22E5400FFE8F23C54383F666053
> < S31A000051235AA96D8068F2920004600661FF00000448F22E54000B
> < S31A00005138FFE0F23C54383F5995369285B1F4F294001AF22E5490
> < S31A0000514D00FFE0F23C54383F59953692CC105AF2920004600695
> ---
>> S31A0000510EA94A514CF294001AF22E5400FFE8F23C54383F66603C
>> S31A000051235AA96D807FF2920004600661FF00000448F22E5400F4
>> S31A00005138FFE0F23C54383F5995369285B222F294001AF22E5461
>> S31A0000514D00FFE0F23C54383F59953692CC1088F2920004600667
>
> The differences between the code generated when linked to a binary and then
> dumped with objdump are too many to post (90k diff file) so its in the file
> /offsite/cassidy/rs6000-others.diff. I don't know if the fact that the
> rs6000 is generating different code than all the other hosts tested, so I
> wanted to let those who would know, know.
>
> cassidy
>
>
> From: cassidy at darkstar.cygnus.com (Jeffrey Wheat)
> Subject: rs6000 differences (920715-1.s)
> To: progressive at darkstar.cygnus.com, testing at darkstar.cygnus.com,
> gumby at darkstar.cygnus.com
> Date: Fri, 25 Jun 1993 16:11:26 -0600 (MDT)
>
> [pluto] [gcc/rs6000-ibm-aix] [pts/3] % diff 920715-1.s ../sparc-sun-sunos4.1.1/920715-1.s
> 23c23
> < fcmpd #0r0.0013165056730000000,fp0
> ---
>> fcmpd #0r0.001316505673000000062,fp0
> 26c26
> < fcmpd #0r0.0013165056740000000,fp0
> ---
>> fcmpd #0r0.001316505674000000058,fp0
> 33c33
> < fcmpd #0r0.0027314921119999900,fp0
> ---
>> fcmpd #0r0.0027314921119999998472,fp0
> 36c36
> < fcmpd #0r0.0027314921129999900,fp0
> ---
>> fcmpd #0r0.0027314921129999998432,fp0
> 43c43
> < fcmpd #0r0.0015614540989999900,fp0
> ---
>> fcmpd #0r0.0015614540989999999183,fp0
> 46c46
> < fcmpd #0r0.0015614540999999900,fp0
> ---
>> fcmpd #0r0.0015614540999999999143,fp0
> 204c204
> < fmuld #0r7.4373772832748258e-06,fp2
> ---
>> fmuld #0r7.4373772832748257769e-06,fp2
> 207c207
> < fmuld #0r3.8580246913580248e-06,fp3
> ---
>> fmuld #0r3.8580246913580247821e-06,fp3
> 299c299
> < fmuld #0r7.4373772832748258e-06,fp2
> ---
>> fmuld #0r7.4373772832748257769e-06,fp2
> 302c302
> < fmuld #0r3.8580246913580248e-06,fp3
> ---
>> fmuld #0r3.8580246913580247821e-06,fp3
> [pluto] [gcc/rs6000-ibm-aix] [pts/3] %
>
> Note that the code that is produced *does* execute cleanly on the target board.
>
> cassidy
>
>
> From: gumby at cygnus.com (D. V. Henkel-Wallace)
> Date: Mon, 28 Jun 93 12:14:03 EDT
> To: gnu at cygnus.com
> Cc: jeffrey at cygnus.com, progressive at cygnus.com
> Subject: rs6000 differences (920715-1.s)
>
> Date: Mon, 28 Jun 93 09:04:11 -0700
> From: gnu at cygnus.com
>
> > Code generated on the IBM RS/6000 by the compiler in this release of
> > the Developer's Kit may differ slightly from that of previous
> > releases. Specifically, this is with respect to the "fcmpd" and
> > "fmuld" commands. Note that the code produced does execute cleanly.
> >
> > "Floating-point numbers for certain cross targets may have excess
> > precision when generated by a compiler running on an R/S 6000."
>
> excess precision?! surely you jest...
>
> No, there are too many bits in the mantissa (oops, it's now called
> something else these days).
>
> We still need to investigate why this is happening.
>
> Mark's already scheduled to fix it for devo, but it won't happen
> before Q2 ships.
--
-Pol Dellaiera-
+32 478 78 30 33
https://not-a-number.io/
More information about the rb-general
mailing list