[Lazarus] EpikTimer v1.0.1 released

[Michael Schnell]

On 06/23/2014 02:51 PM, Sven Barth wrote:
>
> Because you'd need to link in that code then.
>
I don't see the what you mean by this.
vDSO is not really "linked". In an initialization phase, the static 
address of such a function is detected and when you want to call it, you 
just do an indirect call. (OK this is very similar to using an so ;-) .)



> Where should that code be then? The glibc? What about other 
> c-libraries then or FPC's c-library-less approach? A library? Oh wait 
> that needs kernel calls to load...
>

Of course glibc _could_ forward calls to it's traditional functions to 
appropriate vDSO functions, but IMHO a real benefit of such vDSO 
functions would be exactly with languages like fpc that do not (like to) 
use the gnu provided libraries. Here, the RTL easily could do the call 
to the vDSO function, instead of either implementing arch depending 
stuff (like an optimized way of calling the Kernel via "int" or other 
means) but simply do an indirect function call using a pointer 
initialized in the program start phase - which should be easily doable 
in any language.

I did a preliminary test for this in pure fpc code. Seems rather easy.

In fact, in the initialization phase you read a virtual file (in proc) 
and hence you of course do an old-style system call. Hence, if you want 
to do all system calls by an (assumed) vDSO function, before the 
initialization is complete the code does need a fallback to a 
traditional internal "int" based function.

-Michael