[PATCH v1 0/6] TIMESTAMP output section command

Tue Oct 7 17:43:50 GMT 2025

Den 2025-10-07 kl. 18:04, skrev 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.
>
>
>
There is no general use for an expression so that you can do calculations.

There is a general use for having the time stamp in the generated image.

Joseph Myers mentions SOURCE_DATE_EPOCH in another mail

|SOURCE_DATE_EPOCH|is astandardised environment variable 
<https://reproducible-builds.org/specs/source-date-epoch/>that 
distributions can set centrally and have build tools consume this in 
order to produce reproducible output.
In practice,|SOURCE_DATE_EPOCH|specifies the last modification of 
something, usually the source code, measured in the number seconds since 
the Unix epoch, ie.|January 1st 1970, 00:00:00 UTC|.

so it appears there is a recommended standard here, and while my patches 
do not implement this, they use exactly the same definition of time.

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

And as You see from SOURCE_DATE_EPOCH seconds after epoch is what the 
world is converging to.

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

The 32 bit counters will wrap-around in 2038.
So 32-bit timestamps does not make sense at all.

>
> Jan

-- 
Best Regards,
Ulf Samuelsson
+46722 427437
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251007/04ba5751/attachment-0001.htm>