> Yeah, it's not very convenient. I didn't find any real alternatives,
> though, and you can always just put 0xfffff000 in memory or registers and
> jump to that.
Putting the value into memory myself is not possible. In a DSO I have
to address memory indirectly. But all registers (except %ebp, and maybe
it'll be used some day) are used at the time of the call.
But there is a way: if I'm using
#define makesyscall(name) \
movl $__NR_##name, $eax; \
call 0xfffff000-__NR_##name($eax)
and you'd put at address 0xfffff000 the address of the entry point the
wrappers wouldn't have any problems finding it.
> In fact, I suspect that if you actually want to use it in
> glibc, then at least in the short term that's what you need to do anyway,
> sinc eyou probably don't want to have a glibc that only works with very
> recent kernels.
That's a compilation option. We might want to do dynamic testing and
yes, a simple pointer indirection is adequate.
But still, the problem is detecting the capable kernels. You have said
not long ago that comparing kernel versions is wrong. And I agree. It
doesn't cover backports and nothing. But there is a lack of an alternative.
If you don't like the process-global page thingy (anymore) the
alternative would be a sysconf() system call.
-- --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `---------------------------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/