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 Joseph, > On Mon, 6 May 2019, Lukasz Majewski wrote: > > > > So, which is (or will be) the case in 5.1 release? Padding > > > ignored or not? > > > > As confirmed in the other mail - the padding is ignored in Linux > > kernel (and the fix patch for x32 is up its way to be pulled). > > Did the patch to ignore padding (for compat syscalls under 64-bit > kernels, non-x32) make it into the final 5.1 release? As fair as I can tell, it was not pulled to 5.1. > > > > It's possible it's __SYSCALL_WORDSIZE, except that's only defined > > > for x86_64, so would need to be made more generally available if > > > it's to be used here. And if made more generally available, it > > > would need a careful comment explaining exactly what it means. > > > > Cannot we just use __WORDSIZE != 64 as proposed by Stepan? > > (for x32 we would have it defined by default) > > > > #if __WORDSIZE != 64 > > # if __LINUX_KERNEL_VERSION >= 0x050100 > > # define __ASSUME_TIME64_SYSCALLS 1 > > # endif > > #endif > > > > Such approach would allow us to avoid introducing new abstraction > > (__SYSCALL_WORDSIZE). > > There are lots of implementation possibilities, including using > __WORDSIZE and undefining for x32, or using __WORDSIZE and defining > the __NR_* macros locally for x32. > > At the present stage of review, I'm not really concerned with such > implementation details. Rather, I'm reviewing things at the level of > concepts and abstractions, and how we document those concepts and > abstractions. The things we need to define here are: > > * What are the sets of syscalls related to 64-bit time, with the > property that, in any given kernel, either all the syscalls in such a > set are present, or all the syscalls in such a set are absent? The 64 bit versions of syscalls (like clock_settime64 or clock_gettime64) are available since 5.1 kernel (as you posted already the following patch: "Update syscall-names.list for Linux 5.1" . I've now only focused on clock_settime(64) to make the discussion more concrete. > > Right now, maybe there's only one such set, and the subset of it > being used in glibc can be defined by listing the syscalls. In > future, there may well be more than one such set - for example, if > syscalls that currently only have versions using timeval get new > versions using timespec that are added even on architectures where > the pre-5.1 kernel syscall interface already uses 64-bit time. This may also happen, yes. > > * For each set of syscalls, what is the *best* logical description of > the set of kernel configurations that has those syscalls? IMHO, the description is as follows: "Time related syscalls with explicit 64 bit time support to be run on archs with 32 bit pointer/long (__WORDSIZE==32)" Hence the __ASSUME_TIME64_SYSCALLS seems to be a descriptive name (as even in the kernel some syscalls end with _time64 suffix - i.e. sched_rr_get_interval_time64) . > There may > be many equivalent descriptions of the current set of such > configurations; we need to find one that is correct, unambiguous, > succinct, close to the actual logic in the kernel that determines > whether those syscalls are present, and has the least chance of being > inaccurate for future kernel configurations. > As stated above - those syscalls are supposed to be used on systems with __WORDSIZE==32 [*] to provide support for 64 bit time (Y2038 safe). > Once we have those concepts clearly defined, we can then look at how > to translate them into code. > > Since (a) future architectures all use asm-generic and (b) the > asm-generic code uses __BITS_PER_LONG == 32, that suggests something > in terms of the size of "long" is the right way to describe the > condition for the presence of the syscalls - at which point you then > need to discuss how the size of "long" can vary between ABIs, and how > in the x32 case the size of "long" in the syscall interface is not > the same as the normal size of that C type. > > Within glibc, __WORDSIZE corresponds to the size of "long", so that > in turn suggests an implementation approach based on __WORDSIZE in > some way, That was the approach took in v3 of the patch set [1] (I do send patches to show the big picture about the idea and most of all - IMHO it is easier to discuss the concept with some code available) > if you have an exception for x32. > Yes, x32 is special :-) (I'm wondering though what is the percentage of glibc users, who use this particular ABI...) Note: [*] - x32 is a special case and (as proposed in the v3 patch set) shall #undef the __ASSUME_TIME64_SYSCALLS as it uses syscalls from x86_64 [1] - https://patchwork.ozlabs.org/patch/1096343/ 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:
pgpxpLrNu1GHQ.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] |