[lld] [LLD] Use uint64_t timestamp to overcome potential overflow (PR #81665)

[Martin Storsjö via llvm-commits]

================
@@ -1830,7 +1830,7 @@ void LinkerDriver::linkerMain(ArrayRef<const char *> argsArr) {
       StringRef value(*epoch);
       if (value.getAsInteger(0, config->timestamp))
         fatal(Twine("invalid SOURCE_DATE_EPOCH timestamp: ") + value +
-              ".  Expected 32-bit integer");
+              ".  Expected 64-bit integer");
     } else {
       config->timestamp = time(nullptr);
----------------
mstorsjo wrote:

Right - but this is a false positive, or at least, the fix does not avoid the issue, at most silencing the static analysis warning in a way that obfuscates the real issue.

Currently we have this:
```
uint32_t config_timestamp = time(nullptr);
uint32_t pe_header_timestamp = config_timestamp;
```

After this change, we'd have this instead:
```
uint64_t config_timestamp = time(nullptr);
uint32_t pe_header_timestamp = config_timestamp;
```
The truncation of timestamps still exists just as much, but it just happens elsewhere (and the change distorts the range of valid inputs in the command line parameter at the same time). Also do note that the potentially 64 bit `time_t` gets stored in an unsigned 32 bit field, so the issue does not appear in 2038, but only in year 2106.

https://github.com/llvm/llvm-project/pull/81665