From: Cory Fields <cory@coryfields.com>
To: binutils@sourceware.org
Cc: Cory Fields <cory@coryfields.com>
Subject: [PATCH] Facilitate deterministic pe executables between linker invocations
Date: Tue, 01 Oct 2013 17:40:00 -0000 [thread overview]
Message-ID: <1380649206-19367-1-git-send-email-cory@coryfields.com> (raw)
I'm not sure if this has been discussed before, or exactly how to propose this
behavioral change, so I'm submitting this patch with the goal of starting a
discussion.
It's currently not possible to create two byte-exact exe's due to the timestamp
in the PE header. This does not match elf behavior, where successive runs can
produce the exact same binary.
Only a tiny change is needed to avoid the random result. An
(entirely arbitrary) value of 1 is hard-coded rather than using the current
timestamp.
Is there a historical reason for the non-deterministic behavior? If so, would
it be reasonable to add an option similar to enable-deterministic-archives to
disable it?
Before:
$ ~/dev/binutils/ld/ld-new -m i386pe -o test.exe <snip>
$ md5sum test.exe
d88f78cff7e0f6cf50f4be546c2b4189 test.exe
$ ~/dev/binutils/ld/ld-new -m i386pe -o test.exe <snip>
$ md5sum test.exe
7287892f03f067940b508db830cf85ac test.exe
After:
$ ~/dev/binutils/ld/ld-new -m i386pe -o test.exe <snip>
$ md5sum test.exe
fa0bf1a326b332f72f270ae060fa758c test.exe
$ ~/dev/binutils/ld/ld-new -m i386pe -o test.exe <snip>
$ md5sum test.exe
fa0bf1a326b332f72f270ae060fa758c test.exe
binutils/Changelog
10-01-2013 Cory Fields <cory@coryfields.com>
* bfd/peXXigen.c (_bfd_XXi_only_swap_filehdr_out): Use a constant rather
than a real timestamp in the PE header to ensure deterministic link
results when invoked with identical inputs.
---
bfd/peXXigen.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/bfd/peXXigen.c b/bfd/peXXigen.c
index d0f7a96..2d9f93c 100644
--- a/bfd/peXXigen.c
+++ b/bfd/peXXigen.c
@@ -793,7 +793,10 @@ _bfd_XXi_only_swap_filehdr_out (bfd * abfd, void * in, void * out)
H_PUT_16 (abfd, filehdr_in->f_magic, filehdr_out->f_magic);
H_PUT_16 (abfd, filehdr_in->f_nscns, filehdr_out->f_nscns);
- H_PUT_32 (abfd, time (0), filehdr_out->f_timdat);
+ /* use a constant for the timestamp to ensure deterministic results with
+ identical inputs */
+ H_PUT_32 (abfd, 1, filehdr_out->f_timdat);
+
PUT_FILEHDR_SYMPTR (abfd, filehdr_in->f_symptr,
filehdr_out->f_symptr);
H_PUT_32 (abfd, filehdr_in->f_nsyms, filehdr_out->f_nsyms);
--
1.8.1.2
next reply other threads:[~2013-10-01 17:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 17:40 Cory Fields [this message]
2013-10-09 19:08 ` Cory Fields
2013-10-10 14:11 ` nick clifton
2013-10-10 14:40 ` Cory Fields
2013-10-10 18:48 ` Cory Fields
2013-10-11 11:13 ` nick clifton
2013-11-19 0:34 ` Cory Fields
2013-11-20 17:08 ` Cory Fields
2013-11-20 17:56 ` nick clifton
2013-11-20 20:18 ` Cory Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1380649206-19367-1-git-send-email-cory@coryfields.com \
--to=cory@coryfields.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).