Created attachment 7569 [details]
a simple case
There is a timestamp bug in ld 2.24.
ld 2.24 introduced a new "feature" that sets timestamp flag in the Windows PE header to zero by default to make deterministic binaries. However, BindImage / BindImageEx of imagehlp library (bound import technology) relies on the timestamp flag in the PE header, and it's widely used in Windows system DLLs and VB6 compilation process. A reference of the bound import technology can be found at http://msdn.microsoft.com/en-us/magazine/cc301808.aspx. ld 2.24 sets the timestamp to zero by default, thus caused a serious bug.
For example, one exe was bound to a series of dlls built by ld 2.24, which sets timestamp field in the PE header to zero by default. One of the dlls has security issues and producer wants to update it with a new version, also built by ld 2.24, and of course the timestamp field is all the same. Then the exe crashes after patching the new dll.
Steps to reproduce this bug:
Here is a simple example in the attachment.
make -f dll1.mak // make the dll
make -f exe.mak // make the exe
bindimage exe.exe // bind the exe to the dll
exe 1 2 // run the exe, everything is ok
make -f dll2.mak // update the dll with patched version
exe 1 2 // the exe crashes
However, if using ld 2.23 to retry these steps, the exe won't crash at all.
Insert timestamp *BY DEFAULT*, delete the option --insert-timestamp, and add the option --no-timestamp to make deterministic binaries to meet someone's needs.
Also the strip command will accidently erase the timestamp field of EXE/DLLs.