[PATCH v1 0/6] TIMESTAMP output section command

[Ulf Samuelsson]

Den 2025-10-07 kl. 16:48, skrev 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

You assume there is a "general use", and in my experience there is no 
"general use".

It is only used to create a (pseudo) unique identifier and an 
approximate date.

And you want higher resolution without an argument why the resolution is 
not enough.

That system time is off, is a problem at the company which is 
responsible for releasing the image.
If they do not detect that the system time is off in a release, then 
they have a significant problem,
and this is very minor part here.

If they release two images with the same timestamp, again they have a 
problem, that should be addressed elsewhere.
If two engineers are both developing the same thing, and have two images 
with the same timestamp,
it won't matter, because there will be an official build and this is the 
timestamp that will be used.

In short, it will be a unique identifier in any professional development 
process.

A higher resolution would imply other things.
Someone that desires high resolution, certainly wants control over 
exactly when in the linking process the time is read.

Should the time be when the linking starts? Why?
It certainly cannot be when the linking ends, which intuitively would be 
more desirable.

An expression introduces the possibility of bugs. Is there anything 
stopping you from adding a timestamp as an 8/16/32-bit value.

And there is nothing that stops those that are desperate for an 
expression to motivate this and add support in the linker. I predict it 
will never happen.


-- 
Best Regards
Ulf Samuelsson