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

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

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

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

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.

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

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

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

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

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

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

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 been v

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 +0000, 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) that "a si

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 +0000, 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) that "a si

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?

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?

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

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

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

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

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

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

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

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

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*

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*

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

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

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

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

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

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

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

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

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

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

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

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

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: > 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

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

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

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

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: > > 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

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

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.

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.

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 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 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

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

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

her than 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 <jos...@codesourcery.com> --- Please note that I encountered this problem with older kernels, and while the relevant area has not cha

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

her than 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 ana

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

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

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

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

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

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

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 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. > >

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. > >

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

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

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 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 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

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 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

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

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

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

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

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 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. > >

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 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, >

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, >

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

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

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

  1   2   >