aboutsummaryrefslogtreecommitdiff
path: root/cpu
diff options
context:
space:
mode:
authorJon Turney <jon.turney@dronecode.org.uk>2020-01-15 17:03:48 +0000
committerJon Turney <jon.turney@dronecode.org.uk>2020-01-30 13:06:27 +0000
commitb5d36aaa8ad9b0aee720b7a6b3270d561a27cb6f (patch)
tree7c7a97fac1c81463e4494077c15cd5ed8e5882fe /cpu
parent1957ab1030b40939544c88c1c4eb1b8a62bd0b5d (diff)
downloadgdb-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')
0 files changed, 0 insertions, 0 deletions