[PATCH v1 0/6] TIMESTAMP output section command

[Jan Beulich]

On 07.10.2025 16:36, Ulf Samuelsson wrote:
> 
> Den 2025-10-07 kl. 16:17, skrev 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).
> 
> I have worked in the embedded world as an application engineer for 
> microprocessors
> for most of the time since 1984, and I have not seen a single use for 
> having
> a TIME variable in the linker that would be more useful over simply 
> storing the linker time.
> 
> You use it to compare two images.
> If they do not have the same timestamp, they are not the same.
> If they have the same timestamp, then you will still be able to check 
> other things like the CRC.
> You also often printout the time of the build, and that is about it.
> 
> Since you have no experience with this, why not discuss it with someone 
> that has experience with embedded systems?

That's what we're doing, aren't we? What I'm not happy with is that you
focus on just embedded. A new linker directive imo would better be of
general use.

Jan