[PATCH v1 0/6] TIMESTAMP output section command

[Ulf Samuelsson]

Den 2025-10-08 kl. 08:08, skrev Jan Beulich:
> On 07.10.2025 19:43, Ulf Samuelsson wrote:
>> Den 2025-10-07 kl. 18:04, skrev Jan Beulich:
>>> On 07.10.2025 17:05, Ulf Samuelsson wrote:
>>>> 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.
> Did you miss my remark towards signed vs unsigned interpretation of 32-bit
> values? Unsigned counters will have another 68 years to go afaict. Also,
> what about someone wanting to conserve on space, storing e.g. only a 48-bit
> value? (All such considerations fall under "general purpose" from my pov.)
>
> Jan

Looking into the linker, the function to set a timestamp already exist 
for object files,
and as Joseph Myers points out, there is already a function to do this 
in the linker.

bfd_get_current_time will read SOURCE_DATE_EPOCH if present, and if not 
use current time.
There is no way to use that in an expressions.
The timestamp is assigned from this function.

Why should we do anything different, just because it is for an embedded 
system?

-- 
Best Regards
Ulf Samuelsson