[PATCH v1 0/6] TIMESTAMP output section command

[Jan Beulich]

On 07.10.2025 16:02, Ulf Samuelsson wrote:
> 
> 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?

I don't work in the embedded world, so I simply don't know. As a maintainer
I do, however, care about additions being generic enough for everyone to
use them (if wanted).

Jan