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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
