Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack

On Thu, 3 Dec 2020, Florian Weimer wrote: > My knowledge of probability theory is quite limited, so I have to rely > on simulations. But I think you would see a 40 GiB gap somewhere for a > 47-bit address space with 32K allocations, most of the time. Which is > not too bad. This is very close t

Re: Ping(3): [PATCH v4] : Add nitems()

On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote: > Nice! > Please update me on any feedback you receive. Apparently the author is planning new versions of those papers so WG14 discussion is waiting for those. > So glibc will basically hold this patch > at least until the WG answers

Re: Ping(3): [PATCH v4] : Add nitems()

I've asked the WG14 reflector why N2529 (and N2530, though that one's not relevant to this feature) doesn't seem to have made it onto a meeting agenda yet, when there have been two WG14 meetings since that proposal was made and a third one coming up. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)

On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: > I managed to get a repository up and running for librseq, and have integrated > the rseq.2 man page with comments from Michael Kerrisk here: > > https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2 > > Is that a suitable URL

Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)

On Thu, 4 Jun 2020, Mathieu Desnoyers via Libc-alpha wrote: > That external piece of documentation would be part of the Linux man-pages > project, maintained by Michael Kerrisk. I have submitted a few revisions > of the rseq(2) man page, but have been waiting for Michael to reply for more > than a

Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)

On Wed, 3 Jun 2020, Florian Weimer via Libc-alpha wrote: > I'm still waiting for feedback from other maintainers whether the level > of documentation and testing is appropriate. Looking at the documentation in the manual, it doesn't look like it has enough information for someone to use this fun

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On Thu, 18 Apr 2019, Mathieu Desnoyers wrote: > The approach above should work for arm32 be8 vs be32 linker weirdness. > > For aarch64, I think we can simply do: > > /* > * aarch64 -mbig-endian generates mixed endianness code vs data: > * little-endian code and big-endian data. Ensure the RSEQ

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On Wed, 17 Apr 2019, Mathieu Desnoyers wrote: > > +/* RSEQ_SIG is a signature required before each abort handler code. > > + > > + It is a 32-bit value that maps to actual architecture code compiled > > + into applications and libraries. It needs to be defined for each > > + architecture. Wh

Re: [Y2038] Question regarding support of old time interfaces beyond y2038

On Thu, 7 Mar 2019, Lukasz Majewski wrote: > > 1) We should be clear that most of these will continue to be supported > > as C library interfaces even if they are not system calls. Some of > > them are obsolete enough and/or rarely used enough that we might not > > bother (the older ways to set t

Re: [PATCH 7/8] csky: Use latest system call ABI

On Mon, 18 Feb 2019, Arnd Bergmann wrote: > We don't yet have an upstream glibc port for csky, so there is no user We do. It's in 2.29. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6)

On Wed, 30 Jan 2019, Mathieu Desnoyers wrote: > #if defined (__NR_rseq) && !defined (RSEQ_SIG) > # error "UAPI headers support rseq system call, but glibc does not define > RSEQ_SIG." > #endif > > Would that take care of your concerns ? That would of course need appropriate conditionals based o

Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6)

On Tue, 29 Jan 2019, Mathieu Desnoyers wrote: > My thinking was to put the #error in the generic header, so architectures that > are not supported yet cannot build against rseq.h at all, so we don't end up > in a broken upgrade scenario. I'm open to alternative ways to do it though, as > long as w

Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6)

On Tue, 29 Jan 2019, Mathieu Desnoyers wrote: > I recalled that aarch64 defines RSEQ_SIG to a different value which maps to > a valid trap instruction. So I plan to move the RSEQ_SIG define to per-arch > headers like this: > > sysdeps/unix/sysv/linux/aarch64/bits/rseq.h | 24 +

Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038

On Thu, 10 Jan 2019, Arnd Bergmann wrote: > - Add system calls that have not yet been integrated into all > architectures but that we definitely want there. glibc has a note that alpha lacks statfs64, any plans for that? -- Joseph S. Myers jos...@codesourcery.com

Re: d_off field in struct dirent and 32-on-64 emulation

On Fri, 28 Dec 2018, Adhemerval Zanella wrote: > >> Currently we only have nios2 and csky (unfortunately). But since generic > >> definition for off_t and off64_t still assumes non-LFS support, all new > >> 32-bits ports potentially might carry the issue. > > > > For csky, we could still change

Re: Can we drop upstream Linux x32 support?

On Thu, 13 Dec 2018, Florian Weimer wrote: > Similarly, we could have integer types with trap representations. C++2a will require two's complement representation for integer types, with no trap representations (other than for bool, where only 0 and 1 are valid representations). It seems very p

Re: Can we drop upstream Linux x32 support?

On Wed, 12 Dec 2018, Arnd Bergmann wrote: > > MIPS had o32, n32, n64 since like forever. > > o32 and n32 are practically the same, the only difference on the > syscall ABI that I can see are the actual syscall numbers, and > the 'struct sigcontext' definition. And for syscalls that have 64-bit a

Re: [PATCH v3 0/6] mips: system call table generation support

On Thu, 6 Dec 2018, Maciej W. Rozycki wrote: > On Thu, 6 Dec 2018, Joseph Myers wrote: > > > > I believe this file is used by the glibc build process to retrieve > > > syscall numbers for glibc's own use as well for . Has the > > > change b

Re: [PATCH v3 0/6] mips: system call table generation support

On Thu, 6 Dec 2018, Maciej W. Rozycki wrote: > I believe this file is used by the glibc build process to retrieve > syscall numbers for glibc's own use as well for . Has the > change been verified not to break this process? > > Cc-ing for information and possible further > input. I'm not

Re: Official Linux system wrapper library?

On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: > On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote: > > On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: > > > > > That's great. But is it or is it not true (either de jure or de > > > facto) th

Re: Official Linux system wrapper library?

On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: > That's great. But is it or is it not true (either de jure or de > facto) that "a single active glibc developer" can block a system call > from being supported by glibc by objecting? And if not, under what is > the process by resolving a conflict? W

Re: Official Linux system wrapper library?

On Wed, 14 Nov 2018, Daniel Colascione wrote: > A good demonstration of a new commitment to pragmatism would be > merging the trivial wrappers for gettid(2). I support the addition of gettid (for use with those syscalls that take tids, and with appropriate documentation explaining the properties

Re: Official Linux system wrapper library?

On Wed, 14 Nov 2018, Arnd Bergmann wrote: > Firoz Khan is in the process of doing part of this, by changing the > in-kernel per-architecture unistd.h and syscall.S files into a > architecture independent machine-readable format that is used to > generate the existing files. The format will be simi

Re: Official Linux system wrapper library?

On Wed, 14 Nov 2018, Daniel Colascione wrote: > > there is a lot of bikesheding here by people who > > don't understand the constraints nor the use-cases. > > Conversely, there's a lot of doubt-sowing from the other side that "other side" is the wrong concept here in the first place - it's suppo

Re: Official Linux system wrapper library?

On Wed, 14 Nov 2018, Andy Lutomirski wrote: > I’m not so sure it’s useless. Historically, POSIX systems have, in > practice and almost by definition, been very C focused, but the world is > changing. A less crufty library could be useful for newer languages: Historically, there was once an atte

Re: Official Linux system wrapper library?

On Mon, 12 Nov 2018, Daniel Colascione wrote: > I initially wanted to put the APIs in libc. I still do. But that's > proving to be impractical, for the reasons we're discussing on this > thread. Well, your proposed APIs didn't attract consensus among libc developers. > > (I can imagine *other* p

Re: Official Linux system wrapper library?

On Mon, 12 Nov 2018, Daniel Colascione wrote: > The two features *are* unrelated. The design I've proposed works > equally well for synchronous and asynchronous signals, and limiting it Whatever the design, I see no obvious reason why a kernel-provided library, with all the problems that entails

Re: Official Linux system wrapper library?

On Mon, 12 Nov 2018, Florian Weimer wrote: > For that use case, a machine-readable system call ABI specification is > the only reasonable approach: Some people want inline system calls, I also think it's much more likely to be of use to glibc than any syscall library provided by the kernel. I d

Re: Official Linux system wrapper library?

On Mon, 12 Nov 2018, Greg KH wrote: > If there are still problems with this, please let us know and we will be > glad to resolve them. With headers installed from Linus's latest tree, I retried (for x86_64) the case of a source file containing the single line #include which (as previously dis

Re: Official Linux system wrapper library?

On Sun, 11 Nov 2018, Willy Tarreau wrote: > > The kernel developers care not, and the result is that we > > copy definitions and declarations from the kernel header files, creating > > additional problems. > > Probably that these standard compatibility issues should be addressed at > their root i

Re: Official Linux system wrapper library?

On Sun, 11 Nov 2018, Florian Weimer wrote: > The kernel does not know about TCB layout, so a lot of low-level > threading aspects are defined by userspace. > > The kernel does not know about POSIX cancellation. Directly calling > system calls breaks support for that. Indeed. Where cancellation

Re: Official Linux system wrapper library?

On Sun, 11 Nov 2018, Florian Weimer wrote: > People may have disappeared from glibc development who have objected to > gettid. I thought this was the case with strlcpy/strlcat, but it was > not. Well, I know of two main people who were objecting to the notion of adding bindings for all non-obso

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On Thu, 20 Sep 2018, Mathieu Desnoyers wrote: > Something like this in pthreadP.h ? > > +#ifdef __NR_rseq > +#include > +#else > +#include > +#endif /* __NR_rseq. */ > > where sysdeps/unix/sysv/linux/rseq-internal.h contains the linux > implementation of rseq_register_current_thread () and >

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On Thu, 20 Sep 2018, Mathieu Desnoyers wrote: > Are you saying glibc has an explicit check for the kernel version visible > from /proc before using specific features ? If so, how can this work with > the variety of feature backports we find in the distribution kernels out > there ? See sysdeps/un

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On Wed, 19 Sep 2018, Szabolcs Nagy wrote: > i don't think there is precedent for exposing tls symbol in glibc > (e.g. errno is exposed via __errno_location function) so there > might be issues with this (but i don't have immediate concerns). There have been suggestions to expose TLS errno - but a

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On Wed, 19 Sep 2018, Mathieu Desnoyers wrote: > > This looks like it's coming from the Linux kernel. Can't the relevant > > uapi header just be used directly without copying into glibc (with due > > care to ensure that glibc still builds if the kernel headers used for the > > build are too old -

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On Wed, 19 Sep 2018, Mathieu Desnoyers wrote: > Here is a rough prototype registering rseq(2) TLS for each thread > (including main), and unregistering for each thread (excluding > main). "rseq" stands for Restartable Sequences. A final patch would need to add documentation and tests and a NEWS e

Re: [PATCH] [RFC] making uapi/linux/elfcore.h useful again

On Fri, 14 Sep 2018, Arnd Bergmann wrote: > +typedef unsigned long elf_greg_t; Does that need to be unsigned long long for x32? (At least glibc thinks so; I've not tested what an x32 core dump actually looks like, but to be useful it certainly ought to have 64-bit registers.) -- Joseph S. My

Re: RFC: remove the "tile" architecture from glibc

On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote: > On 03/09/2018 05:31 PM, Joseph Myers wrote: > > Note that SH glibc test results need some work - there are a large number > > of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>. > > Proba

Re: RFC: remove the "tile" architecture from glibc

On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote: > I have personally invested a lot of work into the SH port over the > past three years in Debian and I was involved fixing many bugs > and as a result, the port is quite usable. It would be really > disappointing to see it being removed all of

Re: RFC: remove the "tile" architecture from glibc

On Wed, 7 Mar 2018, Arnd Bergmann wrote: > Do you have any updates on this? A related question has come up > for the kernel, as are in the process of removing a number of architectures, > https://lwn.net/SubscriberLink/748074/119aaf0d62b3e6c1/ or > see https://lwn.net/Articles/748074/ for a nice s

[PATCH] powerpc: fix 32-bit ppc_fadvise64_64 for 64-bit offset

EINVAL being returned for the above test. This patch fixes this bug by calling sys_fadvise64_64 directly from ppc_fadvise64_64. Signed-off-by: Joseph Myers --- Please note that I encountered this problem with older kernels, and while the relevant area has not changed recently and the above analys

Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting

On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote: > correct or not. After learn and compare some fuzz tools, I feel that there is > no such fuzz tools could help me. So, I wrote a new fuzz tools base on the > trinity and it found several wrapper issues in glibc. I will first explain the > different wi

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

On Tue, 28 Jun 2016, Yury Norov wrote: > What you talk about sounds unclear to me. If you mean to unify with > one of existing ports, it looks unnecessary, as ilp32 will end up with > RISC-V anyway. If you mean to use RISC-V, it's not ready yet. I was > thinking that when they will finish, they s

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

On Tue, 28 Jun 2016, Yury Norov wrote: > > You can't #include installed headers from other ports like this; it > > wouldn't work when using an installed library. > > > > -- > > Joseph S. Myers > > jos...@codesourcery.com > > So I should copy? Hmm... Yes, unless you can develop an additional a

Re: [PATCH 01/23] [AARCH64] define word size for lp64 and ilp32

On Tue, 28 Jun 2016, Joseph Myers wrote: > On Tue, 28 Jun 2016, Yury Norov wrote: > > > diff --git a/sysdeps/aarch64/bits/wordsize.h > > b/sysdeps/aarch64/bits/wordsize.h > > See what I said in > <https://sourceware.org/ml/libc-alpha/2016-06/msg00786.html> abo

Re: [PATCH 10/23] [AARCH64] Detect ILP32 in configure scripts.

On Tue, 28 Jun 2016, Yury Norov wrote: > On Tue, Jun 28, 2016 at 05:07:49PM +0000, Joseph Myers wrote: > > <https://sourceware.org/ml/libc-alpha/2016-06/msg00785.html> and > > <https://sourceware.org/ml/libc-alpha/2014-10/msg00639.html> still apply. > > Please

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

On Tue, 28 Jun 2016, Yury Norov wrote: > aarch64 and ilp32 has different size of time_t. So to have common > layout for struct utmp and utmpx, corresponding headers are taken > from s390 port. You can't #include installed headers from other ports like this; it wouldn't work when using an install

Re: [PATCH 22/23] off_t: fix register pair calculation for 64-bit case

On Tue, 28 Jun 2016, Yury Norov wrote: > +weak_alias(__posix_fadvise64_l64, __posix_fadvise) Missing space before '('. > +weak_alias(__posix_fallocate64_l64, posix_fallocate) Likewise. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 21/23] [AARCH64] Make __SIZEOF_SEM_T 16 for ILP32

Missing preprocessor indentation. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

still applies. Unify implementations instead of proliferating variants. Also, much of the formatting is way off the GNU Coding Standards (e.g. indentation that's not two-column, "{" not on a line by itself), and you're missing descri

Re: [PATCH 19/23] [AARCH64] delouse input arguments in system functions

Missing spaces before '(' in macro calls. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 17/23] [AARCH64] ILP32: introduce syscalls that pass off_t

On Tue, 28 Jun 2016, Yury Norov wrote: > ILP32 has 64-bit off_t, to follow modern requirements. > But kernel clears top-halves of input registers. It means > we have to pass corresponding arguments in a pair, like > aarch32 does. In this patch all affected syscalls are redefined. > Most of them ar

Re: [PATCH 16/23] [AARCH64] Make lp64 and ilp32 directories.

and still apply. It's clear this won't be ready to go in within the next two days, so use GLIBC_2.25 as symbol version, and be prepared to change it to GLIBC_2.26 or later i

Re: [PATCH 10/23] [AARCH64] Detect ILP32 in configure scripts.

and still apply. Please make the changes requested there before any reposting of the patch series. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 05/23] [AARCH64] Use PTR_REG in crti.S.

On Tue, 28 Jun 2016, Yury Norov wrote: > From: Andrew Pinski > > call_weak_fn loads from a pointer, so use PTR_REG so the load > is 32bits for ILP32. > > * sysdeps/aarch64/crti.S: Include sysdep.h > (call_weak_fn): Use PTR_REG when loading from > PREINIT_FUNCTION. > > AARCH64: Make RTLD_START

Re: [PATCH 06/23] [AARCH64] Use PTR_REG/PTR_SIZE/PTR_SIZE_LOG in dl-tlsesc.S

On Tue, 28 Jun 2016, Yury Norov wrote: > * sysdeps/aarch64/dl-tlsdesc.S (_dl_tlsdesc_return): Use PTR_REG. > (_dl_tlsdesc_dynamic) : Use PTR_REG, PTR_SIZE. > (_dl_tlsdesc_resolve_hold): Likewise. > (_dl_tlsdesc_resolve_rela): Likewise. > (_dl_tlsdesc_return_lazy) : Likewise. >

Re: [PATCH 03/23] Add dynamic ILP32 AARCH64 relocations to elf.h

On Tue, 28 Jun 2016, Yury Norov wrote: > From: Andrew Pinski > > elf/elf.h (R_AARCH64_P32_ABS32, R_AARCH64_P32_COPY, > R_AARCH64_P32_GLOB_DAT, R_AARCH64_P32_JUMP_SLOT, > R_AARCH64_P32_RELATIVE, R_AARCH64_P32_TLS_DTPMOD, > R_AARCH64_P32_TLS_DTPREL, R_AARCH64_P32_TLS_TPREL, > R_AARCH64_P32_TLSDESC

Re: [PATCH 01/23] [AARCH64] define word size for lp64 and ilp32

On Tue, 28 Jun 2016, Yury Norov wrote: > diff --git a/sysdeps/aarch64/bits/wordsize.h b/sysdeps/aarch64/bits/wordsize.h See what I said in about "make other bits/wordsize.h files define the macro to 0". This patch would break all ot

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

On Tue, 28 Jun 2016, Yury Norov wrote: > - addressed v1 comments (I'm really sorry if I missed something, >there are a lot of them, and I am really thankfull for detailed review); You appear to have ignored most of my comments, including comments carried over from 2014. Please check more t

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

On Thu, 23 Jun 2016, Yury Norov wrote: > So for now I think it's simpler to have this ABI in sysdeps, and be in Of course it goes in sysdeps. But not architecture-specific sysdeps. And "simpler" for initial implementation may not be simpler for future maintenance; when there are too many impl

Re: [PATCH 05/27] [AARCH64] Use PTR_REG in crti.S.

On Wed, 22 Jun 2016, Yury Norov wrote: > > As well as preprocessor indentation, this is missing spaces after '('; > > check for and fix that issue throughout this patch series. (There are > > only a few cases where a macro is used to construct a type / variable > > name, such as ElfW, where mi

Re: [PATCH 25/27] [AARCH64] Fix ILP32 warning

On Tue, 21 Jun 2016, Yury Norov wrote: > #define _JMPBUF_CFA_UNWINDS_ADJ(jmpbuf, context, adj) \ > - _JMPBUF_UNWINDS_ADJ (jmpbuf, (void *) _Unwind_GetCFA (context), adj) > + _JMPBUF_UNWINDS_ADJ (jmpbuf, (void *)(size_t) _Unwind_GetCFA (context), > adj) glibc uses spaces in casts, so "(void *)

Re: [PATCH 20/27] [AARCH64] Make lp64 and ilp32 directories.

On Tue, 21 Jun 2016, Yury Norov wrote: > From: Andrew Pinski > > The patch makes the ilp32 and lp64 have their own directory under aarch64. > Since ILP32 uses most of the same system calls as LP64 and has a 64bit > off_t, we need make the functions that end in 64 the same as the ones without. >

Re: [PATCH 27/27] Fix PTRDIFF_MIN/PTRDIFF_MIN and PTRDIFF_MIN for ILP32.

On Tue, 21 Jun 2016, Yury Norov wrote: > +# ifdef __WORDSIZE32_PTRDIFF_LONG > +#define PTRDIFF_MIN (-2147483647L-1) > +#define PTRDIFF_MAX (2147483647L) > +# else > +#define PTRDIFF_MIN (-2147483647-1) > +#define PTRDIFF_MAX (21

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On Tue, 21 Jun 2016, Yury Norov wrote: > From: Andrew Pinski > > NOTE This is an ABI change for AARCH64. My previous comments regarding symbol versioning and warnings in NEWS apply. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 22/27] [AARCH64] ILP32: support stat syscall family

On Tue, 21 Jun 2016, Yury Norov wrote: > From: Yury Norov > > stat and statfs structures has their layouts identical to lp64 > after changing off_t, ino_t etc sizes to 64-bit. It means we can > pass it to kernel same way as lp64 does. This should be implemented in a way suitable for future arch

Re: [PATCH 10/27] [AARCH64] Detect ILP32 in configure scripts.

On Tue, 21 Jun 2016, Yury Norov wrote: > diff --git a/sysdeps/aarch64/preconfigure b/sysdeps/aarch64/preconfigure > index d9bd1f8..4bcd8e3 100644 > --- a/sysdeps/aarch64/preconfigure > +++ b/sysdeps/aarch64/preconfigure > @@ -1,6 +1,15 @@ > case "$machine" in > aarch64*) > base_machine=aar

Re: [PATCH 03/27] Add dynamic ILP32 AARCH64 relocations to elf.h

On Tue, 21 Jun 2016, Yury Norov wrote: > From: Andrew Pinski > > elf/elf.h (R_AARCH64_P32_ABS32, R_AARCH64_P32_COPY, > R_AARCH64_P32_GLOB_DAT, R_AARCH64_P32_JUMP_SLOT, > R_AARCH64_P32_RELATIVE, R_AARCH64_P32_TLS_DTPMOD, > R_AARCH64_P32_TLS_DTPREL, R_AARCH64_P32_TLS_TPREL, > R_AARCH64_P32_TLSDESC

Re: [PATCH 05/27] [AARCH64] Use PTR_REG in crti.S.

On Tue, 21 Jun 2016, Yury Norov wrote: > +#ifdef __LP64__ > +#define RTLD_START RTLD_START_1("x", "3", "sp") > +#else > +#define RTLD_START RTLD_START_1("w", "2", "wsp") > +#endif As well as preprocessor indentation, this is missing spaces after '('; check for and fix that issue throughout this

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

On Tue, 21 Jun 2016, Yury Norov wrote: > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate.c > create mode 100644 sysdeps/unix/sysv/l

Re: [PATCH 23/27] [AARCH64] delouse input arguments in system functions

On Tue, 21 Jun 2016, Yury Norov wrote: > Signed-off-by: Yury Norov You're missing a patch description. What does "delouse" even mean? What is the ABI peculiarity that means there are ABI-conforming arguments to these functions that need such a manipulation? -- Joseph S. Myers jos...@codeso

Re: [RFC PATCH 00/27] ARM64: support ILP32

On Tue, 21 Jun 2016, Yury Norov wrote: > Please review it. Any comments appreciated. General comments: Please make sure you go through all the review comments from the previous patch series posted in Oct 2014 and either address them, or explicitly justify why you think they are incorrect or no

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Tue, 17 May 2016, Szabolcs Nagy wrote: > i think even legacy software should be able to deal with 64bit off_t, > so we could avoid having two sets of filesystem apis or is 64bit-only > off_t more work to do in linux/glibc? wordsize-64 directories generally expect 64-bit interfaces. wordsize-3

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Tue, 17 May 2016, Arnd Bergmann wrote: > I think it has become easier to override now and we just need to > update sysdeps/unix/sysv/linux/generic/bits/typesizes.h to set > > #define __INO64_T_TYPE __UQUAD_TYPE > #define __OFF64_T_TYPE __UQUAD_TYPE > #define __OFF_T_MATCHES_O

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > I think so (along with using wordsize-64 sysdeps directories as far as > > possible, like x32 does). But design questions for a glibc port really > > belong on libc-alpha to get any sort of community consensus. > > I thought the wordsize-64 stuff w

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Tue, 29 Mar 2016, Arnd Bergmann wrote: > How do we do it then? Should we just define __USE_FILE_OFFSET64 > unconditionally for all new 32-bit architectures and leave the > code dealing with 32-bit off_t/ino_t in place but unreachable, to > minimize the differences? Defining __USE_FILE_OFFSET64

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Tue, 29 Mar 2016, Arnd Bergmann wrote: > In glibc, I think we need to define fewer entry points, not more. > Instead of having both lseek and lseek64, only one of them should > be provided, and that should always take a 64-bit offset, calling > into the kernel with the _llseek syscall entry. l

Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote: > > It's not a matter of leaving anything out - these would simply use 64-bit > > off_t (__off_t and __off64_t would be the same type) and the *64 versions > > would be aliases, exactly the same as on 64-bit architectures. (And > > _FILE_OFFSET_BITS ha

Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote: > There are two separate aspects here: > > a) leave out the support for all __off_t based syscalls (__ftruncate, >__lseek, __lxstat, __pread, __preadv, __pwrite, __pwritev, __truncate, >__xstat) as they are no longer needed, and change the handlin

Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote: > Let's not get into the tv_nsec discussion today, that is not thankfully > not relevant for arm64 any more at this point. The system call ABI for > arm64/ilp32 is now the same as for any other 32-bit architecture using > the generic ABI, the question we'r

Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Sun, 15 Nov 2015, Chris Metcalf wrote: > I've added Rich, Paul, Joseph, and Mike to the cc's as they are probably > a good subset of libc-alpha to help comment on these issues. My sense > is that right now, it wouldn't be possible to add a 32-bit architecture > with a non-32-bit default for

Re: Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

On Thu, 20 Aug 2015, Michael Ellerman wrote: > On Wed, 2015-08-19 at 14:39 +0000, Joseph Myers wrote: > > I'd like to ping this patch series, not having seen any comments on it. > > > > [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp > &

Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

I'd like to ping this patch series, not having seen any comments on it. [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp https://lkml.org/lkml/2015/7/2/394 [PATCH 1/8] math-emu: Move math-emu to math-emu-old https://lkml.org/lkml/2015/7/2/395 [PATCH 2/8] math-emu: Imp

[PATCH 8/8] math-emu: Remove math-emu-old

From: Joseph Myers All architectures using math-emu-old having been moved to math-emu by previous patches in this series, this patch removes the old code. Signed-off-by: Joseph Myers --- diff --git a/include/math-emu-old/double.h b/include/math-emu-old/double.h deleted file mode 100644 index

[PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu

From: Joseph Myers This patch moves sparc from math-emu-old to math-emu, updating it for the API changes. The following cleanup (that goes beyond mechanical conversion to new APIs) is included in this patch because of its close connection to the API changes: * On SPARC, comparisons now use raw

[PATCH 6/8] sh/math-emu: Move sh from math-emu-old to math-emu

From: Joseph Myers This patch moves sh from math-emu-old to math-emu, updating it for the API changes. The following cleanups or bug fixes (that might change how the emulation behaves, or that go beyond mechanical conversion to new APIs) are included in this patch because of their close

[PATCH 5/8] s390/math-emu: Move s390 from math-emu-old to math-emu

From: Joseph Myers This patch moves s390 from math-emu-old to math-emu, updating it for the API changes. Thanks to Stefan Liebler in <https://sourceware.org/ml/libc-alpha/2015-04/msg00154.html> for the sysinfo.c changes. Signed-off-by: Joseph Myers --- diff --git a/arch/s390/inclu

[PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu

From: Joseph Myers This patch moves powerpc from math-emu-old to math-emu, updating it for the API changes. The following cleanups or bug fixes (that might change how the emulation behaves, or that go beyond mechanical conversion to new APIs) are included in this patch because of their close

[PATCH 3/8] alpha/math-emu: Move alpha from math-emu-old to math-emu

From: Joseph Myers This patch moves alpha from math-emu-old to math-emu, updating it for the API changes. The following cleanups or bug fixes (that might change how the emulation behaves, or that go beyond mechanical conversion to new APIs) are included in this patch because of their close

[PATCH 1/8] math-emu: Move math-emu to math-emu-old

From: Joseph Myers The include/math-emu code (used for alpha powerpc sh sparc, and to a very limited extent for s390) was taken from an old version of glibc's soft-fp code around 15 years ago (in the pre-git era, anyway, and some of the initial code may have been developed around 1997-9 w

[PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

From: Joseph Myers The include/math-emu code (used for alpha powerpc sh sparc, and to a very limited extent for s390) was taken from an old version of glibc's soft-fp code around 15 years ago (in the pre-git era, anyway, and some of the initial code may have been developed around 1997-9 w

Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

On Tue, 30 Jun 2015, Michael Ellerman wrote: > Is there some way you can imagine of splitting this up into smaller chunks, so > that different arches can merge the pieces separately? Well, it could be split as: 1. Rename include/math-emu to math-emu-old and update architectures for the renaming

Ping Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/maj

Re: String literals in __init functions

On Thu, 26 Mar 2015, Joe Perches wrote: > > I'd have thought that a function-wide > > __attribute__((__string_section__(foo)) > > wouldn't be a ton of work to implement. > > Maybe not. > > Could some future version of gcc move string constants > in a function to a specific section marked in

Re: [PATCH RFC] Update kernel math-emu code from current glibc soft-fp

On Thu, 19 Feb 2015, David Miller wrote: > From: Joseph Myers > Date: Fri, 6 Feb 2015 17:25:29 + > > > * On SPARC, comparisons now use raw unpacking (this should not in fact > > change how the emulation behaves, just make it more efficient). > > I did a sparc

Re: [PATCHv3 00/24] ILP32 support in ARM64

On Wed, 11 Feb 2015, Rich Felker wrote: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437 > > > > Please leave x32 out of this discussion. I have resolved this bug > > as WONTFIX. > > From the glibc side, I thought things went by a consensus process > these days, not the old WONTFIX r

Re: [PATCH RFC] Update kernel math-emu code from current glibc soft-fp

On Fri, 6 Feb 2015, Randy Dunlap wrote: > On 02/06/15 09:25, Joseph Myers wrote: > > At this point this patch is an RFC rather than yet being ready for > > inclusion, because I've only tested it for powerpc (both e500 and > > emulation of classic hard float); it's