Home Original page

[PATCH v1 0/6] TIMESTAMP output section command

Jan Beulich jbeulich@suse.com
Tue Oct 7 13:44:09 GMT 2025 
On 07.10.2025 15:31, Ulf Samuelsson wrote:
> 
> Den 2025-10-07 kl. 15:06, skrev Jan Beulich:
>> On 07.10.2025 14:58, Ulf Samuelsson wrote:
>>> Den 2025-10-07 kl. 14:43, skrev Jan Beulich:
>>>> On 07.10.2025 14:39, binutils@emagii.com wrote:
>>>>> [PATCH v1 1/6] ld:TIMESTAMP command, ldlex.l
>>>>> [PATCH v1 2/6] ld:TIMESTAMP command, ldgram.y
>>>>> [PATCH v1 3/6] ld:TIMESTAMP command, ldlang.*
>>>>> [PATCH v1 4/6] ld:TIMESTAMP info
>>>>> [PATCH v1 5/6] ld:TIMESTAMP ChangeLog
>>>>> [PATCH v1 6/6] ld:TIMESTAMP NEWS
>>>>>
>>>>> ld:TIMESTAMP command
>>>>>       
>>>>> Add TIMESTAMP command to linker.
>>>>>       
>>>>> The TIMESTAMP command inserts a QUAD-word entry with the current time
>>>>> into the image at the current location.
>>>>> The value is the number of seconds since the Epoch,
>>>>> 1970-01-01 00:00:00 +0000 (UTC)
>>>>>
>>>>> The main purpose for the command is for application headers
>>>>> in embedded systems which often require a timestamp to be able to
>>>>> exactly identify the build.
>>>> And those embedded systems all agree on all the field properties? I find
>>>> it hard to believe that anything time related can be "general purpose".
>>> Each company is likely to have their own definition of the application
>>> header
>>> So you create a linker command file that will generate a header
>>> according to your specification.
>>>
>>> Many will want to have a timestamp inside the application header so they
>>> can use
>>> that to ensure that two devices are running exactly the same code.
>>>
>>> The TIMESTAMP is generated using the "time" function which I assume is
>>> what people expect.
>>> It is highly unlikely that a company will release or even build two
>>> different images that are linked in
>>> exactly the same second, so it is enough resolution.
>> A lot of assumptions. I can't help the impression that what we want instead
>> is a time _value_ (at higher precision) which one can then use in arbitrary
>> expressions.
>>
>> Jan
> 
> It is not assumptions. It is based on experience.
> 
> A system that allows new versions of the application to be downloaded
> needs to verify that the application is bona fide before execution if it
> wants to be considered professional.
> 
> Do you disagree with this?
> 
> If an embedded application has problems, you often want to verify the 
> problem
> on another identical unit, and you need to ensure that you run the same 
> software.
> 
> Do you disagree with that?

This is all fine, but doesn't require timestamps to address. See e.g. the
--build-id= option. And you effectively ...

> A timestamp with a one second resolution is in practice a unique 
> identifier that shows you
> if one image is the same as another. I do not see any use for any higher 
> resolution.
> The actual value of the timestamp is not important at all.

... say just that right here. As to 1s resolution - how do you know? Fast
systems may be able to link multiple binaries within a second. Systems'
times may also be off. So no, I don't view a timestamp as a reliable
"unique ID" in the first place. If you want to embed timestamps in
binaries, then only for that very purpose - to record time.

> I fail to see the use of an arbitrary time within the linking process is 
> useful
> in an expression. Please enlighten me with an example when this would be 
> useful.

It would simply allow you to do what you want, while allowing others to
do things even just slightly differently.

Jan
More information about the Binutils mailing list