diff options
author | Jon Turney <jon.turney@dronecode.org.uk> | 2020-01-15 17:03:48 +0000 |
---|---|---|
committer | Jon Turney <jon.turney@dronecode.org.uk> | 2020-01-30 13:06:27 +0000 |
commit | b5d36aaa8ad9b0aee720b7a6b3270d561a27cb6f (patch) | |
tree | 7c7a97fac1c81463e4494077c15cd5ed8e5882fe /cpu/ChangeLog | |
parent | 1957ab1030b40939544c88c1c4eb1b8a62bd0b5d (diff) | |
download | gdb-b5d36aaa8ad9b0aee720b7a6b3270d561a27cb6f.zip gdb-b5d36aaa8ad9b0aee720b7a6b3270d561a27cb6f.tar.gz gdb-b5d36aaa8ad9b0aee720b7a6b3270d561a27cb6f.tar.bz2 |
Identify reproducible builds in 'objdump -p' output for PE files
These are produced by MSVC when the '/Brepro' flag is used.
To quote from the PE specification [1]:
"The presence of an entry of type IMAGE_DEBUG_TYPE_REPRO indicates the
PE file is built in a way to achieve determinism or reproducibility. If
the input does not change, the output PE file is guaranteed to be
bit-for-bit identical no matter when or where the PE is produced.
Various date/time stamp fields in the PE file are filled with part or
all the bits from a calculated hash value that uses PE file content as
input, and therefore no longer represent the actual date and time when a
PE file or related specific data within the PE is produced. The raw data
of this debug entry may be empty, or may contain a calculated hash value
preceded by a four-byte value that represents the hash value length."
[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
bfd/ChangeLog:
2020-01-16 Jon Turney <jon.turney@dronecode.org.uk>
* peXXigen.c (pe_is_repro): New function.
(_bfd_XX_print_private_bfd_data_common): Note timestamp is
actually a build hash if PE_IMAGE_DEBUG_TYPE_REPRO is present.
Diffstat (limited to 'cpu/ChangeLog')
0 files changed, 0 insertions, 0 deletions