This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Stepan, > 02.05.2019 в 10:51:08 +0200 Lukasz Majewski написал: > > Hi Stepan, > > > > > 30.04.2019 в 11:05:05 +0200 Lukasz Majewski написал: > > > > IMHO, the abstraction would be: > > > > > > > > 1. The __ASSUME_64BIT_TIME is _never_ defined for 64 bit native > > > > systems > > > > > > > > 2. It is defined by default in: > > > > sysdeps/unix/sysv/linux/kernel-features.h for 32 bit systems > > > > (and the actual presence of the syscall is decided upon > > > > definitions of __NR_xxx* (i.e. # ifdef > > > > __NR_clock_settime64). > > > > > > I think that __NR_clock_settime64 should be used unconditionally > > > when __ASSUME_64BIT_TIME is defined. > > > > Could you clarify it a bit? > > I meant something like this: > > int > __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp) > { > #ifdef __ASSUME_64BIT_TIME > return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp); > #else > … > > But I see now that most of the existing code would just miscompile in > cases where __ASSUME_* is defined while corresponding __NR_* is not. > > > In the code as proposed in: > > https://patchwork.ozlabs.org/patch/1092583/ > > > > The call to clock_settime64 is protected with # ifdef > > __NR_clock_settime64 - otherwise we do a fallback to (32 bit) > > clock_settime. > > > > Moreover, the # ifdef __ASSUME_64BIT_TIME provides a fallback path > > if kernel version is older than 5.1. > > The fallback would be wrong in cases where __NR_clock_settime is not > defined or is not 32-bit. > > > > > As those syscalls are provided on almost every 32 bit system now > > > > (5.1-rc6): > > > > git grep -n "clock_settime64" > > > > > > > > gives support for: arm, arm64 (compat mode), m68k, microblaze, > > > > mips, parisc, powerpc, s390, sh, sparc, x86, xtensa > > > > > > > > So it would be reasonable to just add this __ASSUME definition > > > > code to sysdeps/unix/sysv/linux/kernel-features.h and #undef it > > > > for architectures not supporting it (i.e. c-sky and riscv). > > > > > > I believe that the only 32-bit architecture without > > > __NR_clock_settime64 is x32. > > > > Ok, I see. > > > > Please correct me - would it be feasible to just #undef > > __ASSYME_TIME64_SYSCALLS for x32 ? > > You'll need to know whether to use __NR_clock_settime64 or > __NR_clock_settime in cases where __TIMESIZE == 64 and > __WORDSIZE == 32. > > One way would be by defining __ASSUME_TIME64_SYSCALLS unconditionally > on x32 and then defining __NR_clock_settime64 to __NR_clock_settime > when __ASSUME_TIME64_SYSCALLS is defined while __NR_clock_settime64 > isn't. > I see. Thanks for the hint. > > > While newer 32-bit architectures like > > > riscv do not have __NR_clock_settime: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4c08b9776b392e20efc6198ebe1bc8ec1911d9b > > > > Then it shall use clock_settime64 from the outset if support > > added. > > It probably should have __TIMESIZE == 64 though. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Attachment:
pgpwVUMMtjgfo.pgp
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |