[Oberon] clock_gettime

[Michael Schierl]

Hello Peter,


Am 11.07.2026 um 17:09 schrieb peter at easthope.ca:
> Hi,
> =================================
> Starting A2 system.
> Unix.Dlsym: entry 'clock_gettime' not found
> Unix.Dlsym: entry 'clock_getres' not found
> GC mode : metadata
> 
> LinuxA2 Gen. 32-bit, Apr 19 2023 2026/07/05 06:04
> 
> Trap 11 (Segmentation violation)
> =================================
> 
> Clock access in an older Linux differs from contemporary Linux. I
> wonder whether Linux.Unix.Mod can determine what is available before
> invoking something certain to fail.  Then invoke something which
> works.

I wonder whether anybody thinks that a segfault happening several lines 
of output after a dlsym warning have anything to do with that dlsym 
being failing. (I would assume the likelyhood to be so to be very minimal).

Anyway, DLSym can fail gracefully, resulting in the procedure pointer to 
be NIL. Which is checked in some places but not all, but I did not 
quickly find a way any of those paths to be called in the startup sequence.

Still, your clock and timer outputs will be wrong, so you'd need to fix 
it if it disturbs you. And in case your TRAP is caused by something 
else, you still need to find and fix that of course, to get the system 
running.


> From A2/source/Linux.Unix.Mod,
> 
> CLOCK_MONOTONIC* = 1;
> CLOCK_MONOTONIC_RAW* = 4;
> CLOCK_PROCESS_CPUTIME_ID* = 2;
> CLOCK_REALTIME* = 0;
> CLOCK_THREAD_CPUTIME_ID* = 3;
> ...
> clock_gettime-	: PROCEDURE {C} (clk_id: INTEGER; tp: ADDRESS): INTEGER;
> clock_getres-	: PROCEDURE {C} (clk_id: INTEGER; res: ADDRESS): INTEGER;
> 
> Web searches reported that the Linux kernel introduced
> CLOCK_MONOTONIC in 2.5.63,
> CLOCK_MONOTONIC_RAW in 2.6.28,
> CLOCK_PROCESS_CPUTIME_ID in 2.6.12,
> CLOCK_REALTIME in 2.6.0,
> CLOCK_THREAD_CPUTIME_ID in 2.6.12,
> clock_gettime in 2.6 and 
> clock_getres in 2.6.
> 
> Whereas in a 32 bit machine here, uname -a reports,
> Linux puppypc 2.6.35.13_xo1.5-20110713.2219.olpc.da7074b_Puppy .
> 
> So the clock calls should work.
> 
> Ideas?

The exported syscalls of a kernel have nothing to do with the exported 
symbols of your C library.

On 32-bit systems which are compiled against 64-bit time_t (to work 
around Y2038 bug), glibc's export is called "__clock_gettime64" instead 
of "clock_gettime", and its ABI signature changed. You can try to dlsym 
both and call whichever is non-NIL.


> 
> Thanks,              ... P.


Hope that helps,


Michael