[PATCH v1 0/6] TIMESTAMP output section command

[Jan Beulich]

On 07.10.2025 17:05, Ulf Samuelsson wrote:
> 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.
> 
> You assume there is a "general use", and in my experience there is no 
> "general use".

In which case I'm inclined to say there's no fit for such a directive in
a general purpose linker.

> 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.

I gave an argument: General usability.

> 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.

8 or 16 bits may not make a lot of sense for a timestamp as a whole.
32 bits already may, especially when not considering this a signed value.
And 8 bits may make quite a bit of sense if someone wanted to decompose
the time stamp.

Jan