Home Original page

[PATCH v1 0/6] TIMESTAMP output section command

Ulf Samuelsson binutils@emagii.com
Tue Oct 7 14:02:31 GMT 2025 
Den 2025-10-07 kl. 15:44, skrev Jan Beulich:
> 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.

It does not matter if application A and application B have the same 
timestamp.
What matters is if two versions of application A has the same timestamp 
but are different.
The same build will not produce the same image twice.

Do you think that your opinion what is reliable is a good decision criteria?
Or is it what is generally considered acceptable in the embedded 
industry that matters?
I have seen the timestamp embedded in a number of applications.
Noone has even suggested a higher resolution.

You can immediately see that one image is not the same as another image 
by looking at the timestamp.

You can immediately see that one image is later than another by looking 
at the timestamp.

Having increased resolution in a timestamp does not change the problem.
It just reduces the likelyhood of collision.
But the likelyhood of collision is so extremely low in real life that it 
does not matter.

>
>> 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.
I doubt you find someone who seriously need to do this differently.
Do you have a single example of someone who needs to do it differently?


> Jan

-- 
Best Regards
Ulf Samuelsson
More information about the Binutils mailing list