On 01.03.22 19:28, Jan Kiszka wrote: > On 21.02.22 14:25, Florian Bezdeka wrote: >> The compat syscall was previously routed to the native entrypoint. >> While the timeout is always based on time64_t the siginfo has to be >> handled different in compat mode. >> >> Signed-off-by: Florian Bezdeka <florian.bezd...@siemens.com> >> --- >> kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h >> b/kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h >> index 1c83ff4e3..3986b227b 100644 >> --- a/kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h >> +++ b/kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h >> @@ -64,6 +64,7 @@ __COBALT_CALL32emu_THUNK(sendmsg) >> __COBALT_CALL32emu_THUNK(mmap) >> __COBALT_CALL32emu_THUNK(backtrace) >> __COBALT_CALL32emu_THUNK(mq_timedreceive64) >> +__COBALT_CALL32emu_THUNK(sigtimedwait64) >> __COBALT_CALL32emu_THUNK(recvmmsg64) >> >> #endif /* !_COBALT_X86_ASM_SYSCALL32_TABLE_H */ > > There are way more new 64-bit calls. Matching their original versions > against this header, I would say we need more thunks, no?
They are necessary only if there is special handling for compat mode needed. Most of the y2038 related syscalls do not need special handling in compat mode as "struct timespec" is now the same in both worlds. I have some cleanup patches pending, which actually will reduce the number of compat stubs. See [1]. It seems I overlooked some header magic adding the compat syscalls into the syscall table at a fixed offset. So we do not have to care "manually". [1] https://gitlab.com/Xenomai/xenomai-hacker-space/-/commits/florian/y2038 > > for time64func in $(git grep 64, kernel/cobalt/posix/syscall32.c | \ > sed 's/.*(\([^6]*\)64,.*/\1/'); do > git grep -q $time64func \ > kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h && \ > echo $time64func; done > > sem_timedwait > clock_getres > clock_gettime > clock_settime > clock_nanosleep > mutex_timedlock > cond_wait_prologue > mq_timedsend > mq_timedreceive > sigtimedwait > monitor_wait > event_wait > recvmmsg > > We now have mq_timedreceive64, sigtimedwait64 and recvmmsg64 with > thunks. There rest is missing, no? > > Interestingly, we also have no thunk for old recvmmsg so far. Probably a > bug of it own. > > Jan >
