[PATCH v2 0/6] TIMESTAMP add expression

[Ulf Samuelsson]

On 2025-10-20 08:08, Fangrui Song wrote:
> On Tue, Oct 14, 2025 at 9:50 AM <binutils@emagii.com> wrote:
>> From: binutils@emagii.com
>> Reply-To:
>> Subject: [PATCH v2 0/6] TIMESTAMP add expression
>> In-Reply-To:
>>
>> ld:TIMESTAMP expression
>>
>> Was: "TIMESTAMP output section command"
>>
>> Add TIMESTAMP expression to linker.
>>
>> The TIMESTAMP expression can be used to insert a timestamp
>> in an output section.
>>
>> Example:
>>          QUAD TIMESTAMP
>>
>> Will insert the timestamp into the image at the current location.
>>
>> The value is retreived using bfd_get_current_time which is
>> how the linker gets timestamp for other things.
>>
>> If the SOURCE_DATE_EPOCH environment variable exist,
>> the value of that will be used if it has a sane value
>> or otherwise the timestamp will be 0.
>> If the SOURCE_DATE_EPOCH does not exist, then the
>> current time will be used.
>> Itis the number of seconds since the Epoch,
>> 1970-01-01 00:00:00 +0000 (UTC)
>>
>> The main purpose for this is for application headers
>> in embedded systems which often require a timestamp to be able to
>> exactly identify the build.
>>
>> For now, it is a patchset of 6 patches.
>> Can be merged into a single patch if/when accepted.
>>
>> [PATCH v2 1/6] ld:TIMESTAMP: ldlex.l
>> [PATCH v2 2/6] ld:TIMESTAMP: ldgram.y
>> [PATCH v2 3/6] ld:TIMESTAMP: testsuite
>> [PATCH v2 4/6] ld:TIMESTAMP: ld.texi
>> [PATCH v2 5/6] ld:TIMESTAMP: NEWS
>> [PATCH v2 6/6] ld:TIMESTAMP: ChangeLog
> I agree with Jan's point that this feature isn't generic enough and
> Joseph's concern that it would introduce a reproducible build pitfall
> when SOURCE_DATE_EPOCH is not set.
> https://sourceware.org/pipermail/binutils/2025-October/144706.html
>
> I don't think we should proceed with this patch series.

Jan did not think the command "TIMESTAMP" was generic enough and wanted 
an expression.
This is what the new implementation provides, so you write

QUAD TIMESTAMP

I can see one advantage with this and it is obvious that a QUAD word is 
generated.
That was not obvious with the TIMESTAMP command.

======
You seem to think that the timestamp is optional.
There are companies where adding a timestamp is not optional.
It is part of the spec.
======

Joseph's concern was that it is not use SOURCE_DATE_EPOCH.
The new implementation uses the bfd_get_current_time
which does use SOURCE_DATE_EPOCH.

His suggestion to use pass a non-standard variable remains.
For users of SOURCE_DATE_EPOCH, that is unnecessary clutter in the 
command line.

For companies which has a standardized format for a header,
adding the TIMESTAMP in a linker include file for the header
is much less intrusive than to maintain each and every build script for 
this feature.

With SOURCE_DATE_EPOCH embedded, it becomes important
information what was used to generate the build. I can certainly see 
that people
may want to add that to each build, outside the embedded world,
and again it is less intrusive than adding support for this in command 
line parameters.

======

Whether companies want reproducible builds or not is up to them.
It is of course a trend, but if needed, the solution is obvious:

Set the SOURCE_DATE_EPOCH environment variable to what you want.

If you already have a method to create timestamps, then you can continue 
to use that.
Odds are that you just passed the output of "/bin/time", which creates a 
non-reproducible build.

This patch allows you to add support for SOURCE_DATE_EPOCH without 
having to change your build scripts.
If you want to implement SOURCE_DATE_EPOCH,  this is a cleaner solution 
that passing it as parameters to the link file.

Ulf Samuelsson
ulf@emagii.com