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

[Joseph Myers]

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 to a Poisson process (if the number of small 
allocations being distributed independently in the address space is 
large), so the probability that any given gap is at least x times the mean 
gap is about exp(-x).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 to that, right?

I think that whether C2x gets an array-size feature of some kind is 
relevant to whether such a feature goes in glibc and what it looks like in 
glibc, but the fact that it will be considered in WG14 doesn't rule out 
glibc considering such a feature without waiting for WG14.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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)

[Joseph Myers]

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 ? Can we simply point to it from glibc's manual ?

Yes, that seems something reasonable to link to.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 year now:
> 
>   
> https://lore.kernel.org/r/2021826204.69809.1588000508294.javamail.zim...@efficios.com
> 
> I'm thinking about hosting a rseq(2) man-page into my librseq project, would
> that make sense ?

I'm not particularly concerned with exactly where it goes, as long as it's 
somewhere stable we can link to.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 functionality, or to know when 
they might want to use it, and nor does it point to external documentation 
of it.  It would seem appropriate at least to include a link to wherever 
the external documentation is of what this functionality is good for, how 
to create and use a "Restartable Sequence critical section", and how to 
"perform rseq registration to the kernel".

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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_SIG signature
>  * matches code endianness.
>  */
> #define RSEQ_SIG_CODE   0xd428bc00  /* BRK #0x45E0.  */
> 
> #ifdef __ARM_BIG_ENDIAN
> #define RSEQ_SIG_DATA   0x00bc28d4  /* BRK #0x45E0.  */
> #else
> #define RSEQ_SIG_DATA   RSEQ_SIG_CODE
> #endif
> 
> #define RSEQ_SIGRSEQ_SIG_DATA
> 
> Feedback is most welcome,

You'll also need __ASSEMBLER__ conditionals in the installed sys/rseq.h 
header so that it only defines constants and doesn't include any C 
declarations in that case, if RSEQ_SIG_CODE is meant to be usable in .S 
files rather than just inline asm in C files.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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. When choosing this value, it needs to be taken into
> > +   account that generating invalid instructions may have ill effects on
> > +   tools like objdump, and may also have impact on the CPU speculative
> > +   execution efficiency in some cases.  */
> > +
> > +#define RSEQ_SIG 0xd428bc00/* BRK #0x45E0.  */
> 
> After further investigation, we should probably do the following
> to handle compiling with -mbig-endian on aarch64, which generates
> binaries with mixed code vs data endianness (little endian code,
> big endian data):

First, the comment on RSEQ_SIG should specify whether it is to be 
interpreted in the code or the data endianness.

> For ARM32, the situation is a bit more complex. Only armv6+
> generates mixed-endianness code vs data with -mbig-endian.
> Prior to armv6, the code and data endianness matches. Therefore,
> I plan to #ifdef the reversed endianness handling with:
> 
> #if __ARM_ARCH >= 6 && __ARM_BIG_ENDIAN
> 
> on arm32.

That doesn't work well because BE code (.o files) can be built for v5te 
(for example) and used on a range of different architecture variants with 
both BE32 and BE8 - the choice between BE32 and BE8 is a link-time choice, 
not a compile-time choice.  So if the value for Arm is a compile-time 
constant, it should also work for both BE32 and BE8.

In turn, that suggests to me that RSEQ_SIG should be defined to be a value 
that is always in the code endianness (and whatever corresponding kernel 
code handles RSEQ_SIG values should act accordingly on architectures where 
the two endiannesses can differ).  If the kernel ABI is already fixed in a 
way that prevents such a definition of RSEQ_SIG semantics as using code 
endianness, a value should be chosen for Arm that works for both 
endiannesses.

(Also, installed glibc headers are supposed to work with older compilers, 
and support for __ARM_ARCH was only added in GCC 4.8.  Before that you 
need to test lots of separate macros for different architecture variants 
to determine a version number.)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 the system clock, for instance).
> 
> The question here is about the decision if even the old time APIs shall
> be supported on 32 bit systems which are going to be Y2038 proof (like
> the 'stime').

The glibc API should support the same set of functions both with and 
without _TIME_BITS=64.

I think it would be reasonable to obsolete the stime function in glibc 
(meaning turn it into a compat symbol, not available for linking new 
programs and not present at all for new architectures).  But that's 
orthogonal to supporting 64-bit times on 32-bit platforms in glibc.  If 
stime is obsoleted before (or in the same release as) that 64-bit time 
support, no 64-bit version of stime is needed in glibc.  If obsoleted in a 
later release, glibc would need to get a 64-bit version (and both versions 
would turn into compat symbols if the interface is obsoleted).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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)

[Joseph Myers]

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 on the most 
recent kernel version for which a given glibc version has been updated, so 
that using new kernel headers with an existing glibc release does not make 
the build fail (cf. the test of syscall-names.list).  And being able to 
write such a test only solves one half of the problem - it needs to be 
easy to determine what value to put in that header in glibc for an 
architecture that's newly gained support in the kernel, *without* needing 
any architecture expertise.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 we don't let not-yet-supported architectures build broken code.

Any case with #error in installed glibc headers needs special-casing in 
check-installed-headers.sh (and, thus, such errors are to be discouraged).

Cases where architectures commonly need their own bits/ headers, 
especially where those are likely to need updating for new kernel 
versions, are also discouraged.  Furthermore, a normal check for glibc 
headers updates needed for a new kernel version would only involve 
examining uapi headers (and the non-uapi linux/socket.h for new address 
families, an unfortunate existing wart in this area).  As far as I can 
see, this value isn't defined in any uapi header, which makes it 
especially likely to be missed in such a check.  Furthermore, I'm hoping 
to add more glibc tests for consistency of such constants between glibc 
and the kernel, to ensure any such updates missing are caught 
automatically through test failures - but that doesn't work if the 
constants in question aren't in a uapi header.

If this constant were in a uapi header, the glibc header could just 
include that - is the issue that it's not actually an interface between 
glibc and the kernel at all, but some kind of purely-userspace interface?

We very definitely wish to keep to a minimum the cases where updates need 
to be done separately in glibc by each architecture maintainer (that's 
just a recipe for some updates getting missed accidentally) - meaning that 
there needs to be a clear way in which someone can tell, globally for all 
architectures, whether the set of such architecture-specific headers for 
this constant in glibc is complete and current, and when it needs updating 
(and this should be as similar to possible to such checks for any other 
header constant).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 ++
>  sysdeps/unix/sysv/linux/arm/bits/rseq.h  |   24 ++
>  sysdeps/unix/sysv/linux/bits/rseq.h  |   23 ++
>  sysdeps/unix/sysv/linux/mips/bits/rseq.h |   24 ++
>  sysdeps/unix/sysv/linux/powerpc/bits/rseq.h  |   24 ++
>  sysdeps/unix/sysv/linux/s390/bits/rseq.h |   24 ++
>  sysdeps/unix/sysv/linux/x86/bits/rseq.h  |   24 ++
> 
> where "bits/rseq.h" contains a #error:
> 
> # error "Architecture does not define RSEQ_SIG.
> 
> sys/rseq.h will now include .

We're trying to reduce the number of cases where most or all new glibc 
architecture ports need to provide a bits/ header, by making the generic 
headers handle the common case.  So a generic header with a #error, and 
lots of architecture-specific headers mostly with the same value for 
RSEQ_SIG, seems unfortunate.  I'd hope the generic header could use a 
generic value, with architecture-specific variants only for architectures 
with some reason for a different value.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

[Joseph Myers]

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 the type of the non-standard d_off
> > field to long long int.  This way, only telldir would have to fail
> > when truncation is necessary, as mentioned below:
> 
> I think it makes no sense to continue making non-LFS as default for
> newer 32 bits ports, the support will be emulated with LFS syscalls.

Any new 32-bit port that uses 64-bit time_t will also use 64-bit offsets 
(because we don't have any glibc configurations that support the 
combination of 64-bit time with 32-bit offsets, and don't want to add 
them).  That should apply for RISC-V 32-bit at least.

I've filed  for 
missing overflow checks in telldir when the default off_t is wider than 
long int (currently just applies to x32; not sure why we don't see glibc 
test failures on x32 resulting from the quiet truncation, as the issue is 
certainly there in the source code).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Can we drop upstream Linux x32 support?

[Joseph Myers]

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 plausible that C will follow.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Can we drop upstream Linux x32 support?

[Joseph Myers]

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 arguments, n32 generally passes those in 
a single register (like n64), not pairs of registers (like o32).  But, 
yes, userspace structure layout for n32 is generally much closer to o32 
than to n64.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 verified not to break this process?
> > > 
> > >  Cc-ing  for information and possible further 
> > > input.
> > 
> > I'm not sure what "this file" is.  The glibc build uses the installed 
> >  (the results of #including it, not any other kind of 
> > processing the file).
> 
>  So how are `SYS_' macros generated that land in ?

By gen-syscall-h.awk, which generates #ifdef conditionals for each 
possible __NR_* name (as listed in syscall-names.list in glibc).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 sure what "this file" is.  The glibc build uses the installed 
 (the results of #including it, not any other kind of 
processing the file).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 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?
> > 
> > We use a consensus-building process as described at 
> > <https://sourceware.org/glibc/wiki/Consensus>.
> 
> So can a single glibc developer can block Consensus?

If it's a sustained objection - it still works an awful lot better than 
how things worked before 2011/12.  (See my suggestion of having a process 
involving a supermajority vote of the GNU maintainers for glibc in the 
rare cases where a consensus cannot be reached - but those are rare enough 
that actually agreeing a process for such cases has never been a 
priority.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 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?
> > 
> > We use a consensus-building process as described at 
> > <https://sourceware.org/glibc/wiki/Consensus>.
> 
> So can a single glibc developer can block Consensus?

If it's a sustained objection - it still works an awful lot better than 
how things worked before 2011/12.  (See my suggestion of having a process 
involving a supermajority vote of the GNU maintainers for glibc in the 
rare cases where a consensus cannot be reached - but those are rare enough 
that actually agreeing a process for such cases has never been a 
priority.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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?

We use a consensus-building process as described at 
.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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?

We use a consensus-building process as described at 
.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 of 
tids) - and, generally, wrappers for all non-obsolescent 
architecture-independent Linux kernel syscalls, including ones that are 
very Linux-specific, except maybe for a few interfaces fundamentally 
inconsistent with glibc managing TLS etc. - they are, at least, no worse 
as a source of APIs than all the old BSD / SVID interfaces we have from 
when those were used as sources of APIs.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 of 
tids) - and, generally, wrappers for all non-obsolescent 
architecture-independent Linux kernel syscalls, including ones that are 
very Linux-specific, except maybe for a few interfaces fundamentally 
inconsistent with glibc managing TLS etc. - they are, at least, no worse 
as a source of APIs than all the old BSD / SVID interfaces we have from 
when those were used as sources of APIs.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 similar to what
> we have on arm/s390/x86 in the syscall.tbl files already.

Will this also mean the following are unable to occur in future (both have 
occurred in the past):

* A syscall added to unistd.h for an architecture, but not added to the 
syscall table until sometime later?

* A syscall added to the native syscall table for some ABI (e.g. 32-bit 
x86 or arm) but not added to the corresponding compat syscall table (e.g. 
32-bit x86 binaries running on x86_64, 32-bit arm binaries running on 
arm64) until sometime later?

Avoiding both of those complications is beneficial to libc (as is a third 
thing, avoiding a syscall being added to different architectures in 
different versions).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 similar to what
> we have on arm/s390/x86 in the syscall.tbl files already.

Will this also mean the following are unable to occur in future (both have 
occurred in the past):

* A syscall added to unistd.h for an architecture, but not added to the 
syscall table until sometime later?

* A syscall added to the native syscall table for some ABI (e.g. 32-bit 
x86 or arm) but not added to the corresponding compat syscall table (e.g. 
32-bit x86 binaries running on x86_64, 32-bit arm binaries running on 
arm64) until sometime later?

Avoiding both of those complications is beneficial to libc (as is a third 
thing, avoiding a syscall being added to different architectures in 
different versions).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 supposed 
to be a matter of cooperating projects trying to find good interfaces 
together.

Any new feature from the kernel that is meant to be of use to libcs is 
best designed in a way involving such cooperation (with multiple libcs).  
I concur with Zack's assessment in 
 that a 
technical fix to process / communication issues cannot work here.  Any 
feature (e.g. syscall library) with a design coming solely from the kernel 
rather than a cooperative process is also likely to have an unsuitable 
design meaning it doesn't get used.  Once we have sufficient communication 
to design suitable interfaces *together*, "avoiding the need to 
communicate" becomes irrelevant as a design criterion anyway.

> After looking at the history of settid, signal multi-handler
> registration, and other proposed improvements running into the brick
> wall of glibc's API process, I think it's clear that requiring glibc
> signoff on new kernel interfaces would simply lead to stagnation. It's

That there was disagreement on some particular interface does not mean 
there are problems with the basic principle of working with libc 
maintainers (of multiple libcs, not just one!) to establish what the 
intended userspace C API to some new kernel interface should be, and to 
nail down the details of how the kernel interface is defined in the 
process.

(And as noted elsewhere, I think the main people objecting to generally 
having bindings for all non-obsolescent syscalls are no longer active in 
glibc.)

If the semantics of some proposed kernel interface, both at the syscall 
level and at the userspace C API level, are agreed e.g. by kernel and musl 
people, I'd think the API agreement from musl would be a good indication 
of the API also being suitable to add to glibc.  It's not necessary to get 
agreement from every libc on every API - but there should be agreement 
from *some* libc that is careful about API review.  If enough people with 
good sense about libc APIs have judged some API for a new syscall 
suitable, I expect other libcs can implement it even if it's not exactly 
the API they'd come up with themselves.

(I haven't seen enough comments on libc / kernel API design from people I 
know to be associated with bionic, uclibc-ng, etc., to judge if they also 
pay similarly careful attention to working out what a good C API design 
for some interface should be.  Note that there are musl people active on 
libc-alpha, which helps everyone arrive at a consensus on better C API 
designs.)

> The right answer is a move to an approximation of the BSD model and
> bring the primary interface layer in-house.

I could equally say we should take the kernel in-house and develop it to 
better support glibc - that if the kernel doesn't provide what we want, we 
should add the features to GNU Linux-libre and say that's the supported 
kernel for use with glibc.  It's an equally absurd statement in a context 
of multiple cooperating projects.

>  There's a lot of evidence that this model works.

There's a lot of evidence that the model of separately maintained Linux 
kernel and libc works (see: the number of devices using Linux kernels with 
a range of different libc implementations that meet different needs).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 supposed 
to be a matter of cooperating projects trying to find good interfaces 
together.

Any new feature from the kernel that is meant to be of use to libcs is 
best designed in a way involving such cooperation (with multiple libcs).  
I concur with Zack's assessment in 
 that a 
technical fix to process / communication issues cannot work here.  Any 
feature (e.g. syscall library) with a design coming solely from the kernel 
rather than a cooperative process is also likely to have an unsuitable 
design meaning it doesn't get used.  Once we have sufficient communication 
to design suitable interfaces *together*, "avoiding the need to 
communicate" becomes irrelevant as a design criterion anyway.

> After looking at the history of settid, signal multi-handler
> registration, and other proposed improvements running into the brick
> wall of glibc's API process, I think it's clear that requiring glibc
> signoff on new kernel interfaces would simply lead to stagnation. It's

That there was disagreement on some particular interface does not mean 
there are problems with the basic principle of working with libc 
maintainers (of multiple libcs, not just one!) to establish what the 
intended userspace C API to some new kernel interface should be, and to 
nail down the details of how the kernel interface is defined in the 
process.

(And as noted elsewhere, I think the main people objecting to generally 
having bindings for all non-obsolescent syscalls are no longer active in 
glibc.)

If the semantics of some proposed kernel interface, both at the syscall 
level and at the userspace C API level, are agreed e.g. by kernel and musl 
people, I'd think the API agreement from musl would be a good indication 
of the API also being suitable to add to glibc.  It's not necessary to get 
agreement from every libc on every API - but there should be agreement 
from *some* libc that is careful about API review.  If enough people with 
good sense about libc APIs have judged some API for a new syscall 
suitable, I expect other libcs can implement it even if it's not exactly 
the API they'd come up with themselves.

(I haven't seen enough comments on libc / kernel API design from people I 
know to be associated with bionic, uclibc-ng, etc., to judge if they also 
pay similarly careful attention to working out what a good C API design 
for some interface should be.  Note that there are musl people active on 
libc-alpha, which helps everyone arrive at a consensus on better C API 
designs.)

> The right answer is a move to an approximation of the BSD model and
> bring the primary interface layer in-house.

I could equally say we should take the kernel in-house and develop it to 
better support glibc - that if the kernel doesn't provide what we want, we 
should add the features to GNU Linux-libre and say that's the supported 
kernel for use with glibc.  It's an equally absurd statement in a context 
of multiple cooperating projects.

>  There's a lot of evidence that this model works.

There's a lot of evidence that the model of separately maintained Linux 
kernel and libc works (see: the number of devices using Linux kernels with 
a range of different libc implementations that meet different needs).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 attempt to rework POSIX into a separate 
language-independent definition and language bindings (for C, Fortran, Ada 
etc.), but I don't think it got anywhere, and it's probably doubtful 
whether the idea was ever very practical.  (See the introduction to 
POSIX.1:1990, for example: "Future revisions are expected to contain 
bindings for other programming languages as well as for the C language.  
This will be accomplished by breaking this part of ISO/IEC 9945 into 
multiple portions---one defining core requirements independent of any 
programming language, and others composed of programming language 
bindings.".)

> > thread internals for syscalls that
> > require coordination between all user created
> > threads (setxid),
> 
> We should just deal with this in the kernel. The current state of 
> affairs is nuts.

Yes, we should have a few new syscalls to set these ids at the process 
level.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 attempt to rework POSIX into a separate 
language-independent definition and language bindings (for C, Fortran, Ada 
etc.), but I don't think it got anywhere, and it's probably doubtful 
whether the idea was ever very practical.  (See the introduction to 
POSIX.1:1990, for example: "Future revisions are expected to contain 
bindings for other programming languages as well as for the C language.  
This will be accomplished by breaking this part of ISO/IEC 9945 into 
multiple portions---one defining core requirements independent of any 
programming language, and others composed of programming language 
bindings.".)

> > thread internals for syscalls that
> > require coordination between all user created
> > threads (setxid),
> 
> We should just deal with this in the kernel. The current state of 
> affairs is nuts.

Yes, we should have a few new syscalls to set these ids at the process 
level.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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* parts of the toolchain being involved, if e.g. you
> > want to have a good way of checking "is the address of the instruction
> > causing this signal in this library?" that works with static as well as
> > dynamic linking - for dynamic linking, I expect something could be done
> > using libc_nonshared and __dso_handle to identify code in the library
> > calling some registering function.  And indeed there might also be new
> > kernel interfaces that help improve signal handling.)
> 
> Again: you're blocking a practical solution for the sake of some
> elegant theoretical implementation that will never arrive, and so the

I'm not - I'm observing various areas that might be open to improvements 
related to signal handling, not saying improvements in one area are a 
prerequisite to improvements in another.  I'm exploring the problem and 
solution space, and collectively exploring the problem and solution space 
is an important part of trying to work out where there might be useful 
future improvements related to the general issue of signal handling.

Exploring the problem and solution space can include coming to the 
conclusion that an idea that seems obvious is in fact a bad idea, or in 
fact orthogonal to other ideas that are independently useful - those 
things are still useful in yielding a better rationale for taking a given 
approach.

> > In the absence of consensus for adding such a new API for signals to
> > glibc, it's unlikely one would get consensus for glibc to depend on some
> > other library providing such an API either.
> 
> glibc would continue using an unsupported legacy system call
> interfaces in lieu of a supported low-level interface library?

The Linux kernel supports the interfaces that people actually use, on the 
principle of not breaking userspace, not the interfaces that someone would 
like to declare to be the supported ones.  We'd use the interfaces that 
seem suitable for use by glibc, and direct syscalls seem more suitable to 
me than any kernel-provided userspace library.

Naturally a library invented in the kernel on the basis of not liking what 
libc people are doing or not doing is unlikely to be suitable for use by 
libc (and use together with libc of anything in it that interferes with 
libc functionality such as sigaction might be explicitly discouraged by 
libc maintainers, just as e.g. direct use of clone can be discouraged) - 
whereas interfaces developed collaboratively with libc implementations and 
getting consensus from those users are more likely to be of use to libc 
implementations.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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* parts of the toolchain being involved, if e.g. you
> > want to have a good way of checking "is the address of the instruction
> > causing this signal in this library?" that works with static as well as
> > dynamic linking - for dynamic linking, I expect something could be done
> > using libc_nonshared and __dso_handle to identify code in the library
> > calling some registering function.  And indeed there might also be new
> > kernel interfaces that help improve signal handling.)
> 
> Again: you're blocking a practical solution for the sake of some
> elegant theoretical implementation that will never arrive, and so the

I'm not - I'm observing various areas that might be open to improvements 
related to signal handling, not saying improvements in one area are a 
prerequisite to improvements in another.  I'm exploring the problem and 
solution space, and collectively exploring the problem and solution space 
is an important part of trying to work out where there might be useful 
future improvements related to the general issue of signal handling.

Exploring the problem and solution space can include coming to the 
conclusion that an idea that seems obvious is in fact a bad idea, or in 
fact orthogonal to other ideas that are independently useful - those 
things are still useful in yielding a better rationale for taking a given 
approach.

> > In the absence of consensus for adding such a new API for signals to
> > glibc, it's unlikely one would get consensus for glibc to depend on some
> > other library providing such an API either.
> 
> glibc would continue using an unsupported legacy system call
> interfaces in lieu of a supported low-level interface library?

The Linux kernel supports the interfaces that people actually use, on the 
principle of not breaking userspace, not the interfaces that someone would 
like to declare to be the supported ones.  We'd use the interfaces that 
seem suitable for use by glibc, and direct syscalls seem more suitable to 
me than any kernel-provided userspace library.

Naturally a library invented in the kernel on the basis of not liking what 
libc people are doing or not doing is unlikely to be suitable for use by 
libc (and use together with libc of anything in it that interferes with 
libc functionality such as sigaction might be explicitly discouraged by 
libc maintainers, just as e.g. direct use of clone can be discouraged) - 
whereas interfaces developed collaboratively with libc implementations and 
getting consensus from those users are more likely to be of use to libc 
implementations.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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, should need to be involved, 
rather than putting new APIs either in libc or in a completely separate 
libsignal for libraries wanting to use such a system for cooperative 
signal use.

(I can imagine *other* parts of the toolchain being involved, if e.g. you 
want to have a good way of checking "is the address of the instruction 
causing this signal in this library?" that works with static as well as 
dynamic linking - for dynamic linking, I expect something could be done 
using libc_nonshared and __dso_handle to identify code in the library 
calling some registering function.  And indeed there might also be new 
kernel interfaces that help improve signal handling.)

In the absence of consensus for adding such a new API for signals to 
glibc, it's unlikely one would get consensus for glibc to depend on some 
other library providing such an API either.  But you can always write a 
library (which I think would most naturally be a completely separate 
libsignal, not part of the kernel source tree) and seek to persuade 
libraries they should be using it rather than interfering with global 
state by registering normal signal handlers directly.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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, should need to be involved, 
rather than putting new APIs either in libc or in a completely separate 
libsignal for libraries wanting to use such a system for cooperative 
signal use.

(I can imagine *other* parts of the toolchain being involved, if e.g. you 
want to have a good way of checking "is the address of the instruction 
causing this signal in this library?" that works with static as well as 
dynamic linking - for dynamic linking, I expect something could be done 
using libc_nonshared and __dso_handle to identify code in the library 
calling some registering function.  And indeed there might also be new 
kernel interfaces that help improve signal handling.)

In the absence of consensus for adding such a new API for signals to 
glibc, it's unlikely one would get consensus for glibc to depend on some 
other library providing such an API either.  But you can always write a 
library (which I think would most naturally be a completely separate 
libsignal, not part of the kernel source tree) and seek to persuade 
libraries they should be using it rather than interfering with global 
state by registering normal signal handlers directly.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 don't think a syscall library provided 
by the kernel is likely to be of use for implementing glibc functions, but 
some kind of textual ABI specification might at least be of use for 
checking that syscall macro calls / syscalls.list entries are consistent 
with what the kernel thinks its ABI is.  (Hopefully there would be 
automated tests on the kernel side as well of some kind of consistency 
between the ABI specification and the kernel.)

strace is indeed a more obvious potential consumer of such a description 
of syscall ABIs.

I'd think a syscall library would more likely be something a few 
applications would use if they want to access a syscall that for whatever 
reason glibc doesn't have a wrapper for yet - not something useful for 
glibc itself to call or link against.

> and for application programmer's sanity, make sure that the kernel adds
> generic system calls in a single version, across all architectures.

That would be strongly desirable for glibc as well - a way of ensuring 
that the kernel rapidly fails CI tests and does not get released if new 
syscalls are only present on some architectures (including e.g. being 
missing from some compat syscall tables, or defined in asm/unistd.h but 
not in the actual syscall table, or vice versa - or some way of making 
sure such inconsistencies cannot occur by eliminating duplicate copies of 
the syscall list information in the sources).

When we have compatibility code in glibc for the absence of some syscall, 
we can only eliminate that code when the oldest kernel version supported 
by glibc is new enough to have the syscall on whichever glibc architecture 
was slowest to introduce the syscall in the kernel - and that can often be 
years after the first architectures gained support for that syscall in the 
kernel.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 don't think a syscall library provided 
by the kernel is likely to be of use for implementing glibc functions, but 
some kind of textual ABI specification might at least be of use for 
checking that syscall macro calls / syscalls.list entries are consistent 
with what the kernel thinks its ABI is.  (Hopefully there would be 
automated tests on the kernel side as well of some kind of consistency 
between the ABI specification and the kernel.)

strace is indeed a more obvious potential consumer of such a description 
of syscall ABIs.

I'd think a syscall library would more likely be something a few 
applications would use if they want to access a syscall that for whatever 
reason glibc doesn't have a wrapper for yet - not something useful for 
glibc itself to call or link against.

> and for application programmer's sanity, make sure that the kernel adds
> generic system calls in a single version, across all architectures.

That would be strongly desirable for glibc as well - a way of ensuring 
that the kernel rapidly fails CI tests and does not get released if new 
syscalls are only present on some architectures (including e.g. being 
missing from some compat syscall tables, or defined in asm/unistd.h but 
not in the actual syscall table, or vice versa - or some way of making 
sure such inconsistencies cannot occur by eliminating duplicate copies of 
the syscall list information in the sources).

When we have compatibility code in glibc for the absence of some syscall, 
we can only eliminate that code when the oldest kernel version supported 
by glibc is new enough to have the syscall on whichever glibc architecture 
was slowest to introduce the syscall in the kernel - and that can often be 
years after the first architectures gained support for that syscall in the 
kernel.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 discussed, and Arnd had an RFC patch) I want to use 
in a glibc test of header consistency.  It gives errors "unknown type name 
'elf_greg_t'" etc. (for lots more types as well) - but even before getting 
onto those errors, there's

asm/signal.h:127:2: error: unknown type name 'size_t'

from a header included from linux/elfcore.h.  So this doesn't seem to be 
working as I'd expect yet.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 discussed, and Arnd had an RFC patch) I want to use 
in a glibc test of header consistency.  It gives errors "unknown type name 
'elf_greg_t'" etc. (for lots more types as well) - but even before getting 
onto those errors, there's

asm/signal.h:127:2: error: unknown type name 'size_t'

from a header included from linux/elfcore.h.  So this doesn't seem to be 
working as I'd expect yet.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 in the kernel header definitions in fact. Working around issues
> always leads to a stall at some point, and it encourages the process not
> to change.

But it's not a bug in the Linux kernel header files.  The set of feature 
test macros supported is libc-specific and libc-version-specific.  The 
internal macros defined as a result of the feature test macros, that 
determine what features to expose, are also libc-specific and 
libc-version-specific.  (The __USE_* macros in glibc are not a stable API.  
For example, we might move to using __GLIBC_USE for more features in place 
of the defined/undefined __USE_* internal macros.)

If a feature is Linux-specific, and the userspace header for it is also 
Linux-specific (as opposed to constants in standard headers such as 
sys/mman.h, where you get all the namespace issues), that userspace header 
*can* include uapi headers in many cases to get constants and structures - 
if those uapi headers actually work in userspace without defining things 
conflicting with libc types.  E.g.  includes 
.

What *is*, in my view, a bug in the uapi headers is that some of them 
don't work when included on their own.  I'd expect #include 
 or #include , for any such header 
installed by make headers_install, to compile on its own in userspace 
without needing any other headers to be included first, unless some header 
is specifically defined as being an internal part of another header which 
is the one that should be included.

In glibc we have scripts/check-installed-headers.sh which verifies that 
installed headers work when included like that in various language 
standard and feature test macro modes - and with my bots running 
build-many-glibcs.py, this property is effectively verified every few 
hours for (currently) 79 different glibc configurations covering all 
supported glibc ABIs.  If the uapi headers are fixed to work on their own, 
there should be similar continuous integration to make sure that this 
continues to be the case in future.

Simply having uapi headers that reliably work when included on their own 
would help with adding further test automation in glibc to verify 
consistency of constant and structure definitions between glibc and uapi 
headers.  We have a few such checks (e.g. for signal numbers), but now 
that we require Python 3 to build glibc I hope to convert those into more 
general infrastructure for extracting information from headers and running 
checks on the extracted information.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 in the kernel header definitions in fact. Working around issues
> always leads to a stall at some point, and it encourages the process not
> to change.

But it's not a bug in the Linux kernel header files.  The set of feature 
test macros supported is libc-specific and libc-version-specific.  The 
internal macros defined as a result of the feature test macros, that 
determine what features to expose, are also libc-specific and 
libc-version-specific.  (The __USE_* macros in glibc are not a stable API.  
For example, we might move to using __GLIBC_USE for more features in place 
of the defined/undefined __USE_* internal macros.)

If a feature is Linux-specific, and the userspace header for it is also 
Linux-specific (as opposed to constants in standard headers such as 
sys/mman.h, where you get all the namespace issues), that userspace header 
*can* include uapi headers in many cases to get constants and structures - 
if those uapi headers actually work in userspace without defining things 
conflicting with libc types.  E.g.  includes 
.

What *is*, in my view, a bug in the uapi headers is that some of them 
don't work when included on their own.  I'd expect #include 
 or #include , for any such header 
installed by make headers_install, to compile on its own in userspace 
without needing any other headers to be included first, unless some header 
is specifically defined as being an internal part of another header which 
is the one that should be included.

In glibc we have scripts/check-installed-headers.sh which verifies that 
installed headers work when included like that in various language 
standard and feature test macro modes - and with my bots running 
build-many-glibcs.py, this property is effectively verified every few 
hours for (currently) 79 different glibc configurations covering all 
supported glibc ABIs.  If the uapi headers are fixed to work on their own, 
there should be similar continuous integration to make sure that this 
continues to be the case in future.

Simply having uapi headers that reliably work when included on their own 
would help with adding further test automation in glibc to verify 
consistency of constant and structure definitions between glibc and uapi 
headers.  We have a few such checks (e.g. for signal numbers), but now 
that we require Python 3 to build glibc I hope to convert those into more 
general infrastructure for extracting information from headers and running 
checks on the extracted information.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 is involved, glibc needs to know exactly what 
instructions might be calling a cancellable syscall and what instructions 
are before or after the syscall (see Adhemerval's patches for bug 12683).

This involves an ABI that is not just specific to a particular libc, but 
specific to a particular libc version.  So it's inherently unsuitable to 
put cancellable syscalls in libc_nonshared.a, as well as unsuitable to put 
them in any kernel-provided library.

The interface for setting errno may also be libc-specific, for any 
syscalls involving setting errno.

Syscalls often involve types in their interfaces such as off_t and struct 
timespec.  libcs may have multiple different variants of those types; the 
variants available, and the ways of selecting them, are libc-specific and 
libc-version-specific.  So for any syscall for which the proper userspace 
interface involves one of those types, wrappers for it are inherently 
specific to a particular libc and libc version.  (See e.g. how preadv2 and 
pwritev2 syscalls also have preadv64v2 and pwritev64v2 APIs in glibc, with 
appropriate redirections hased on __USE_FILE_OFFSET64, which is in turn 
based on _FILE_OFFSET_BITS.)

There are many ABI variants that are relevant to glibc but not to the 
kernel.  Some of these involve ABI tagging of object files to indicate 
which ABI variant an object is built for (and those that don't have such 
tagging ought to have it), to prevent accidental linking of objects for 
different ABIs.  How to build objects for different userspace ABIs is not 
something the kernel should need to know anything about; it's most 
naturally dealt with at the level of building compiler multilibs and libc.

glibc deliberately avoids depending at compile time on the existence of 
libgcc_s.so to facilitate bootstrap builds (a stripped glibc binary built 
with a C-only static-only inhibit_libc GCC that was built without glibc 
should be identical to the result of a longer alternating sequence of GCC 
and glibc builds).  I don't think any kernel-provided library would be any 
better to depend on.

What one might suggest is that when new syscalls are added, kernel 
developers should at least obtain agreement on linux-api from libc people 
about what the userspace interface to the syscall should be.  That means 
the userspace-level types (such as off_t and struct timespec), and the 
choice of error handling (returning error number or setting errno), and 
the name of the header declaring the function, and the name of the 
function, and how the syscall relates to thread cancellation, for example 
- and whatever other issues may be raised.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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 is involved, glibc needs to know exactly what 
instructions might be calling a cancellable syscall and what instructions 
are before or after the syscall (see Adhemerval's patches for bug 12683).

This involves an ABI that is not just specific to a particular libc, but 
specific to a particular libc version.  So it's inherently unsuitable to 
put cancellable syscalls in libc_nonshared.a, as well as unsuitable to put 
them in any kernel-provided library.

The interface for setting errno may also be libc-specific, for any 
syscalls involving setting errno.

Syscalls often involve types in their interfaces such as off_t and struct 
timespec.  libcs may have multiple different variants of those types; the 
variants available, and the ways of selecting them, are libc-specific and 
libc-version-specific.  So for any syscall for which the proper userspace 
interface involves one of those types, wrappers for it are inherently 
specific to a particular libc and libc version.  (See e.g. how preadv2 and 
pwritev2 syscalls also have preadv64v2 and pwritev64v2 APIs in glibc, with 
appropriate redirections hased on __USE_FILE_OFFSET64, which is in turn 
based on _FILE_OFFSET_BITS.)

There are many ABI variants that are relevant to glibc but not to the 
kernel.  Some of these involve ABI tagging of object files to indicate 
which ABI variant an object is built for (and those that don't have such 
tagging ought to have it), to prevent accidental linking of objects for 
different ABIs.  How to build objects for different userspace ABIs is not 
something the kernel should need to know anything about; it's most 
naturally dealt with at the level of building compiler multilibs and libc.

glibc deliberately avoids depending at compile time on the existence of 
libgcc_s.so to facilitate bootstrap builds (a stripped glibc binary built 
with a C-only static-only inhibit_libc GCC that was built without glibc 
should be identical to the result of a longer alternating sequence of GCC 
and glibc builds).  I don't think any kernel-provided library would be any 
better to depend on.

What one might suggest is that when new syscalls are added, kernel 
developers should at least obtain agreement on linux-api from libc people 
about what the userspace interface to the syscall should be.  That means 
the userspace-level types (such as off_t and struct timespec), and the 
choice of error handling (returning error number or setting errno), and 
the name of the header declaring the function, and the name of the 
function, and how the syscall relates to thread cancellation, for example 
- and whatever other issues may be raised.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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-obsolescent syscalls, Linux-specific if not suitable 
for adding to the OS-independent GNU API, and neither seems to have posted 
in the past year.

> At present, it takes one semi-active glibc contributor to block addition
> of a system call.  The process to override a sustained objection has
> never been used successfully, and it is a lot of work to get it even
> started.

We don't have such a process.  (I've suggested, e.g. in conversation with 
Carlos at the Cauldron, that we should have something involving a 
supermajority vote of the GNU maintainers for glibc in cases where we're 
unable to reach a consensus in the community as a whole.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Official Linux system wrapper library?

[Joseph Myers]

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-obsolescent syscalls, Linux-specific if not suitable 
for adding to the OS-independent GNU API, and neither seems to have posted 
in the past year.

> At present, it takes one semi-active glibc contributor to block addition
> of a system call.  The process to override a sustained objection has
> never been used successfully, and it is a lot of work to get it even
> started.

We don't have such a process.  (I've suggested, e.g. in conversation with 
Carlos at the Cauldron, that we should have something involving a 
supermajority vote of the GNU maintainers for glibc in cases where we're 
unable to reach a consensus in the community as a whole.)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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
> rseq_unregister_current_thread (), and sysdeps/nptl/rseq-internal.h
> contains stubs.
> 
> Am I on the right track ?

It's hard to define the right abstractions for what goes where given that 
only Linux uses NPTL since the removal of the NaCl port.  I suppose it 
does make logical sense for a #include of  to go somewhere 
under sysdeps/unix/sysv/linux/.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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
> rseq_unregister_current_thread (), and sysdeps/nptl/rseq-internal.h
> contains stubs.
> 
> Am I on the right track ?

It's hard to define the right abstractions for what goes where given that 
only Linux uses NPTL since the removal of the NaCl port.  I suppose it 
does make logical sense for a #include of  to go somewhere 
under sysdeps/unix/sysv/linux/.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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/unix/sysv/linux/dl-sysdep.c and 
sysdeps/unix/sysv/linux/dl-osinfo.h.  As I said, Carlos has proposed 
removing that check.

> For too-old headers at compile time, one possibility is that we don't event
> expose the __rseq_abi TLS symbol. OTOH, if we need to keep exposing it anyway
> for ABI consistency purposes, then we'd leave its cpu_id field at the initial
> value (-1). But that would require that we copy linux/rseq.h into the glibc
> source tree.

The ABI needs to be independent of the kernel headers used.  I don't think 
you need to copy linux/rseq.h; all you should need is to e.g. define an 
array of suitable size and alignment with the relevant member initialized 
and a suitable explanatory comment.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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/unix/sysv/linux/dl-sysdep.c and 
sysdeps/unix/sysv/linux/dl-osinfo.h.  As I said, Carlos has proposed 
removing that check.

> For too-old headers at compile time, one possibility is that we don't event
> expose the __rseq_abi TLS symbol. OTOH, if we need to keep exposing it anyway
> for ABI consistency purposes, then we'd leave its cpu_id field at the initial
> value (-1). But that would require that we copy linux/rseq.h into the glibc
> source tree.

The ABI needs to be independent of the kernel headers used.  I don't think 
you need to copy linux/rseq.h; all you should need is to e.g. define an 
array of suitable size and alignment with the relevant member initialized 
and a suitable explanatory comment.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 also suggestions 
that use of __errno_location is more efficient, at least in terms of code 
size everywhere errno is accessed (for some ABIs, anyway).

The ABI tests have code that would list .tbss symbols as "T" in ABI test 
baselines, but no existing ABI baselines use that.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 also suggestions 
that use of __errno_location is more efficient, at least in terms of code 
size everywhere errno is accessed (for some ABIs, anyway).

The ABI tests have code that would list .tbss symbols as "T" in ABI test 
baselines, but no existing ABI baselines use that.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 - you need such conditionals anyway if they don't define
> > the relevant syscall number)?
> 
> This is indeed in the list of "things to consider" I've put in the patch
> commit message. If the usual practice is to build against uapi kernel headers
> outside of the glibc tree, I'm fine with that.

We build with, currently, 3.2 or later headers (since 3.2 is EOL there's a 
case for updating the minimum in glibc for both compile time and runtime, 
but I haven't proposed that since there isn't much cleanup that would 
enable and there's the open question of Carlos's proposal to eliminate the 
runtime check on the kernel version and just let things try to run anyway 
even if it's older than the configured minimum).  Functions depending on 
new syscalls may return ENOSYS errors if the headers used to build glibc 
were too old.  Since this patch is providing a data interface rather than 
functions that can set errno to ENOSYS, presumably you have some other way 
of signalling unavailability which would apply both with a too-old kernel 
at runtime and too-old headers at compile time.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 - you need such conditionals anyway if they don't define
> > the relevant syscall number)?
> 
> This is indeed in the list of "things to consider" I've put in the patch
> commit message. If the usual practice is to build against uapi kernel headers
> outside of the glibc tree, I'm fine with that.

We build with, currently, 3.2 or later headers (since 3.2 is EOL there's a 
case for updating the minimum in glibc for both compile time and runtime, 
but I haven't proposed that since there isn't much cleanup that would 
enable and there's the open question of Carlos's proposal to eliminate the 
runtime check on the kernel version and just let things try to run anyway 
even if it's older than the configured minimum).  Functions depending on 
new syscalls may return ENOSYS errors if the headers used to build glibc 
were too old.  Since this patch is providing a data interface rather than 
functions that can set errno to ENOSYS, presumably you have some other way 
of signalling unavailability which would apply both with a too-old kernel 
at runtime and too-old headers at compile time.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 entry 
and fix various coding style issues.

> diff --git a/nptl/Versions b/nptl/Versions
> index e7f691da7a..7316c2815d 100644
> --- a/nptl/Versions
> +++ b/nptl/Versions
> @@ -275,6 +275,7 @@ libpthread {
>  mtx_init; mtx_lock; mtx_timedlock; mtx_trylock; mtx_unlock; mtx_destroy;
>  call_once; cnd_broadcast; cnd_destroy; cnd_init; cnd_signal;
>  cnd_timedwait; cnd_wait; tss_create; tss_delete; tss_get; tss_set;
> +__rseq_abi; __rseq_refcount;

That's the GLIBC_2.28 section, but 2.28 is already out.  New symbols would 
need to go in GLIBC_2.29 or later (and the ABI test baselines would all 
need updating).

> diff --git a/sysdeps/unix/sysv/linux/rseq.h b/sysdeps/unix/sysv/linux/rseq.h

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 - you need such conditionals anyway if they don't define 
the relevant syscall number)?

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 entry 
and fix various coding style issues.

> diff --git a/nptl/Versions b/nptl/Versions
> index e7f691da7a..7316c2815d 100644
> --- a/nptl/Versions
> +++ b/nptl/Versions
> @@ -275,6 +275,7 @@ libpthread {
>  mtx_init; mtx_lock; mtx_timedlock; mtx_trylock; mtx_unlock; mtx_destroy;
>  call_once; cnd_broadcast; cnd_destroy; cnd_init; cnd_signal;
>  cnd_timedwait; cnd_wait; tss_create; tss_delete; tss_get; tss_set;
> +__rseq_abi; __rseq_refcount;

That's the GLIBC_2.28 section, but 2.28 is already out.  New symbols would 
need to go in GLIBC_2.29 or later (and the ABI test baselines would all 
need updating).

> diff --git a/sysdeps/unix/sysv/linux/rseq.h b/sysdeps/unix/sysv/linux/rseq.h

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 - you need such conditionals anyway if they don't define 
the relevant syscall number)?

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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>.  
> > Probably most could be addressed with the NaN fixes I outlined at 
> > <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that 
> > does of course need someone to do the work to implement that in GCC and 
> > glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> > seem very specific on this, but the existing setting was definitely 
> > determined by testing on hardware.  SH experts with access to a range of 
> > different hardware may be needed to advise on what different hardware does 
> > or is supposed to do in this regard.)
> 
> Ok, thanks for the explanation.
> 
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.

"make check", or "make -k check" if you're concerned about some tests 
failing to build (e.g. the compiler running out of memory on a few large 
tests) - the testsuite should continue after execution failures, but not 
after compilation failures.  (Having previously configured with 
--prefix=/usr for the build.  And if the compiler used doesn't have 
libgcc_s and libstdc++ shared libraries in directories ld.so searches by 
default, you should copy those libraries into the glibc build directory 
before running tests.)  On a system that can handle it you'd use an 
appropriate -jN option for parallelism, but probably not on m68k.

For cross testing over SSH (when glibc is running on a system that is very 
slow running the compiler or has too little memory to do so) you need a 
shared filesystem at the same path on both the system where glibc is built 
and the system where tests will execute (probably NFS-exported from the 
build system, and it may be necessary to mount it on the test system with 
acdirmax=0,acdirmin=0 to limit any caching).  Then you can pass 
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh " to make 
check.

In both cases, for very slow test systems you may wish to export 
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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>.  
> > Probably most could be addressed with the NaN fixes I outlined at 
> > <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that 
> > does of course need someone to do the work to implement that in GCC and 
> > glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
> > seem very specific on this, but the existing setting was definitely 
> > determined by testing on hardware.  SH experts with access to a range of 
> > different hardware may be needed to advise on what different hardware does 
> > or is supposed to do in this regard.)
> 
> Ok, thanks for the explanation.
> 
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.

"make check", or "make -k check" if you're concerned about some tests 
failing to build (e.g. the compiler running out of memory on a few large 
tests) - the testsuite should continue after execution failures, but not 
after compilation failures.  (Having previously configured with 
--prefix=/usr for the build.  And if the compiler used doesn't have 
libgcc_s and libstdc++ shared libraries in directories ld.so searches by 
default, you should copy those libraries into the glibc build directory 
before running tests.)  On a system that can handle it you'd use an 
appropriate -jN option for parallelism, but probably not on m68k.

For cross testing over SSH (when glibc is running on a system that is very 
slow running the compiler or has too little memory to do so) you need a 
shared filesystem at the same path on both the system where glibc is built 
and the system where tests will execute (probably NFS-exported from the 
build system, and it may be necessary to mount it on the test system with 
acdirmax=0,acdirmin=0 to limit any caching).  Then you can pass 
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh " to make 
check.

In both cases, for very slow test systems you may wish to export 
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 a sudden :(.

Note that SH glibc test results need some work - there are a large number 
of failures listed at .  
Probably most could be addressed with the NaN fixes I outlined at 
 - but that 
does of course need someone to do the work to implement that in GCC and 
glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
seem very specific on this, but the existing setting was definitely 
determined by testing on hardware.  SH experts with access to a range of 
different hardware may be needed to advise on what different hardware does 
or is supposed to do in this regard.)

The glibc port whose test results cause me the most concern that it's 
effectively unmaintained and should be considered for obsoletion is 
MicroBlaze - the results 
 are clearly a 
big mess (not something where one fix would probably resolve most failures 
as on SH) and there's no sign of activity to sort them out (nor has there 
been such activity for a long time).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 a sudden :(.

Note that SH glibc test results need some work - there are a large number 
of failures listed at .  
Probably most could be addressed with the NaN fixes I outlined at 
 - but that 
does of course need someone to do the work to implement that in GCC and 
glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
seem very specific on this, but the existing setting was definitely 
determined by testing on hardware.  SH experts with access to a range of 
different hardware may be needed to advise on what different hardware does 
or is supposed to do in this regard.)

The glibc port whose test results cause me the most concern that it's 
effectively unmaintained and should be considered for obsoletion is 
MicroBlaze - the results 
 are clearly a 
big mess (not something where one fix would probably resolve most failures 
as on SH) and there's no sign of activity to sort them out (nor has there 
been such activity for a long time).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

No-one has posted glibc test results for 2.27 or 2.26, despite the prior 
claims of interest in keeping the glibc port.  If the kernel port is 
removed, my assumption is that we should remove the glibc port at that 
point (not keep it around for possible use with older kernels).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

No-one has posted glibc test results for 2.27 or 2.26, despite the prior 
claims of interest in keeping the glibc port.  If the kernel port is 
removed, my assumption is that we should remove the glibc port at that 
point (not keep it around for possible use with older kernels).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

Consider the following test, built for 32-bit powerpc and run under a
32-bit kernel.

#define _GNU_SOURCE
#include 
#include 
#include 
#include 

int
main (void)
{
  int fd = open ("/dev/null", O_RDWR);
  int ret = posix_fadvise64 (fd, 0, -1, POSIX_FADV_NORMAL);
  if (ret == EINVAL)
puts ("posix_fadvise64 returned EINVAL as expected");
  else
printf ("posix_fadvise64 returned %d, expected EINVAL = %d\n",
ret, EINVAL);
  close (fd);
  return 0;
}

For 32-bit powerpc, posix_fadvise64 uses the fadvise64_64 syscall.
The negative length means it should return EINVAL.

That syscall uses the ppc_fadvise64_64 function to rearrange the
arguments into the form used by the architecture-independent syscall
implementation.  That function calls sys_fadvise64.  sys_fadvise64
uses type size_t for the length argument, and passes its arguments
through to sys_fadvise64_64, which uses type loff_t.

This works OK under a 64-bit kernel, where size_t is 64-bit.  Under a
32-bit kernel, however, passing the length through sys_fadvise64
results in it being truncated to 32-bit size_t and then zero-extended
back to 64-bit, so resulting in 0 rather 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 changed recently and the above
analysis and this patch are based on current sources, I ran into an
unrelated build failure when attempting to build current kernels to
test this fix.  Thus, the patch should only be applied given testing
that the problem is indeed reproducible with current 32-bit kernels
and is fixed by this patch.

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index de04c9f..7753f77 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -119,8 +119,8 @@ long ppc64_personality(unsigned long personality)
 long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
  u32 len_high, u32 len_low)
 {
-   return sys_fadvise64(fd, (u64)offset_high << 32 | offset_low,
-(u64)len_high << 32 | len_low, advice);
+   return sys_fadvise64_64(fd, (u64)offset_high << 32 | offset_low,
+   (u64)len_high << 32 | len_low, advice);
 }
 
 long sys_switch_endian(void)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

Consider the following test, built for 32-bit powerpc and run under a
32-bit kernel.

#define _GNU_SOURCE
#include 
#include 
#include 
#include 

int
main (void)
{
  int fd = open ("/dev/null", O_RDWR);
  int ret = posix_fadvise64 (fd, 0, -1, POSIX_FADV_NORMAL);
  if (ret == EINVAL)
puts ("posix_fadvise64 returned EINVAL as expected");
  else
printf ("posix_fadvise64 returned %d, expected EINVAL = %d\n",
ret, EINVAL);
  close (fd);
  return 0;
}

For 32-bit powerpc, posix_fadvise64 uses the fadvise64_64 syscall.
The negative length means it should return EINVAL.

That syscall uses the ppc_fadvise64_64 function to rearrange the
arguments into the form used by the architecture-independent syscall
implementation.  That function calls sys_fadvise64.  sys_fadvise64
uses type size_t for the length argument, and passes its arguments
through to sys_fadvise64_64, which uses type loff_t.

This works OK under a 64-bit kernel, where size_t is 64-bit.  Under a
32-bit kernel, however, passing the length through sys_fadvise64
results in it being truncated to 32-bit size_t and then zero-extended
back to 64-bit, so resulting in 0 rather 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
analysis and this patch are based on current sources, I ran into an
unrelated build failure when attempting to build current kernels to
test this fix.  Thus, the patch should only be applied given testing
that the problem is indeed reproducible with current 32-bit kernels
and is fixed by this patch.

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index de04c9f..7753f77 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -119,8 +119,8 @@ long ppc64_personality(unsigned long personality)
 long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
  u32 len_high, u32 len_low)
 {
-   return sys_fadvise64(fd, (u64)offset_high << 32 | offset_low,
-(u64)len_high << 32 | len_low, advice);
+   return sys_fadvise64_64(fd, (u64)offset_high << 32 | offset_low,
+   (u64)len_high << 32 | len_low, advice);
 }
 
 long sys_switch_endian(void)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 with existing fuzz tools and paste my propsosal in the end.

I'm not at all clear on whether any of the people working on AArch64 ILP32 
glibc have run the glibc testsuite and investigated the results in detail 
(the patch submissions have failed to include glibc testsuite results and 
have included bugs that would have been detected by the glibc testsuite).  
But, if you've found bugs in a new glibc port that were not detected by 
the existing testsuite, then tests for those bugs should be contributed to 
glibc (even if no existing port has those bugs, improving the test 
coverage is still a good idea).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 with existing fuzz tools and paste my propsosal in the end.

I'm not at all clear on whether any of the people working on AArch64 ILP32 
glibc have run the glibc testsuite and investigated the results in detail 
(the patch submissions have failed to include glibc testsuite results and 
have included bugs that would have been detected by the glibc testsuite).  
But, if you've found bugs in a new glibc port that were not detected by 
the existing testsuite, then tests for those bugs should be contributed to 
glibc (even if no existing port has those bugs, improving the test 
coverage is still a good idea).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 simply switch this port to
> their code. Am I too optimistic?

I mean unify in sysdeps/unix/sysv/linux (or .../generic if inappropriate 
for the main sysdeps/unix/sysv/linux), for all architectures, both 
existing and new, with conditionals based on logical features of the 
architectures.  If any architecture has its own implementation, it should 
only be old architectures with their special peculiarities.

> Is there glibc analogue for kernel scripts/checkpatch.pl? If yes,
> please point me out, and I'll briefly fix all issues. If no please be

I'm not aware of an analogue, although GCC's contrib/check_GNU_style.sh 
may well be helpful for some issues.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 simply switch this port to
> their code. Am I too optimistic?

I mean unify in sysdeps/unix/sysv/linux (or .../generic if inappropriate 
for the main sysdeps/unix/sysv/linux), for all architectures, both 
existing and new, with conditionals based on logical features of the 
architectures.  If any architecture has its own implementation, it should 
only be old architectures with their special peculiarities.

> Is there glibc analogue for kernel scripts/checkpatch.pl? If yes,
> please point me out, and I'll briefly fix all issues. If no please be

I'm not aware of an analogue, although GCC's contrib/check_GNU_style.sh 
may well be helpful for some issues.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 abstraction to describe the 
differences between architectures, so that all architectures can share the 
same bits/utmp.h and bits/utmpx.h and there's only a smaller header that 
needs copying.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 abstraction to describe the 
differences between architectures, so that all architectures can share the 
same bits/utmp.h and bits/utmpx.h and there's only a smaller header that 
needs copying.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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> about "make 
> other bits/wordsize.h files define the macro to 0".  This patch would 
> break all other architectures (and AArch64 LP64 - you should test build 
> and testsuite for that, as well as ILP32, and confirm that there are no 
> testsuite regressions for LP64).

(Actually, for LP64, if you can confirm that the installed stripped shared 
libraries are byte-for-byte identical before and after the patch series, 
then a testsuite run is unnecessary.  But you still need to run the 
testsuite for ILP32, and justify any failures there, and if the LP64 
binaries aren't byte-for-byte identical, you should justify why they 
aren't.)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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> about "make 
> other bits/wordsize.h files define the macro to 0".  This patch would 
> break all other architectures (and AArch64 LP64 - you should test build 
> and testsuite for that, as well as ILP32, and confirm that there are no 
> testsuite regressions for LP64).

(Actually, for LP64, if you can confirm that the installed stripped shared 
libraries are byte-for-byte identical before and after the patch series, 
then a testsuite run is unnecessary.  But you still need to run the 
testsuite for ILP32, and justify any failures there, and if the LP64 
binaries aren't byte-for-byte identical, you should justify why they 
aren't.)

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 make the changes requested there before any reposting of the patch 
> > series.
> 
> Yes, I forgot about glibc version. I don't want to add changelogs
> because I think patches order should/may be changed, and as all that
> changelogs touch single file, there will be nightmare to rebase
> series.

The convention is that you include the ChangeLog entry as part of the 
patch description, rather than changing the ChangeLog file, to avoid this 
issue.  But with the formatting exactly matching what would go in the 
ChangeLog file, so that for the final commit you just need to update the 
date in it and then prepend to the ChangeLog file.

> >> 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=aarch64
> >> - machine=aarch64
> >> + case "$CC $CFLAGS $CPPFLAGS " in
> >> + *" -mabi=ilp32 "*) aarch64_config_abi=ilp32 ;;
> >> + *" -mabi=lp64 "*) aarch64_config_abi=lp64 ;;
> >> + *) aarch64_config_abi=default ;;
> >> + esac
> >> + case $aarch64_config_abi in
> >> + default) machine=aarch64/lp64 aarch64_config_abi=lp64
> >> ;;
> > 
> > It would seem better to test how the compiler behaves (what it 
> > predefines), as now done for MIPS, so that this works with a compiler 
> > configured --with-abi=ilp32 without needing to add an explicit ABI
> > option 
> > to CC or CFLAGS.
> 
> I didn't understand what you mean here and forgot to ask.
> I didn't work much on glibc, and not familiar to it's build
> system. Could you explain it little more detailed please?

See sysdeps/mips/preconfigure.  It runs $CC $CFLAGS $CPPFLAGS -E -dM -xc 
/dev/null and extracts predefined macros that relate to the ABI from the 
output.  This avoids needing to hardcode anything about what the default 
ABI might be for a compiler if neither -mabi= option is passed.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 make the changes requested there before any reposting of the patch 
> > series.
> 
> Yes, I forgot about glibc version. I don't want to add changelogs
> because I think patches order should/may be changed, and as all that
> changelogs touch single file, there will be nightmare to rebase
> series.

The convention is that you include the ChangeLog entry as part of the 
patch description, rather than changing the ChangeLog file, to avoid this 
issue.  But with the formatting exactly matching what would go in the 
ChangeLog file, so that for the final commit you just need to update the 
date in it and then prepend to the ChangeLog file.

> >> 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=aarch64
> >> - machine=aarch64
> >> + case "$CC $CFLAGS $CPPFLAGS " in
> >> + *" -mabi=ilp32 "*) aarch64_config_abi=ilp32 ;;
> >> + *" -mabi=lp64 "*) aarch64_config_abi=lp64 ;;
> >> + *) aarch64_config_abi=default ;;
> >> + esac
> >> + case $aarch64_config_abi in
> >> + default) machine=aarch64/lp64 aarch64_config_abi=lp64
> >> ;;
> > 
> > It would seem better to test how the compiler behaves (what it 
> > predefines), as now done for MIPS, so that this works with a compiler 
> > configured --with-abi=ilp32 without needing to add an explicit ABI
> > option 
> > to CC or CFLAGS.
> 
> I didn't understand what you mean here and forgot to ask.
> I didn't work much on glibc, and not familiar to it's build
> system. Could you explain it little more detailed please?

See sysdeps/mips/preconfigure.  It runs $CC $CFLAGS $CPPFLAGS -E -dM -xc 
/dev/null and extracts predefined macros that relate to the ABI from the 
output.  This avoids needing to hardcode anything about what the default 
ABI might be for a compiler if neither -mabi= option is passed.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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

[Joseph Myers]

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

[Joseph Myers]

Missing preprocessor indentation.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

Missing preprocessor indentation.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

 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 descriptions as first lines of many new files.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

Missing spaces before '(' in macro calls.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

 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 descriptions as first lines of many new files.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

Missing spaces before '(' in macro calls.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 are taken from arm code.

Please follow the spirit of Adhemerval's recent work.  Determine the 
appropriate abstractions for the architecture differences for these 
syscalls, and set up unified implementations used on all architectures, 
rather than increasing the number of architecture-specific variants.

> +#ifdef __ILP32__
> +/* Define this if your 32-bit syscall API requires 64-bit register
> +   pairs to start with an even-number register.  */
> +#define __ASSUME_ALIGNED_REGISTER_PAIRS  1
> +#endif /* __ILP32__ */

Preprocessor indentation.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 are taken from arm code.

Please follow the spirit of Adhemerval's recent work.  Determine the 
appropriate abstractions for the architecture differences for these 
syscalls, and set up unified implementations used on all architectures, 
rather than increasing the number of architecture-specific variants.

> +#ifdef __ILP32__
> +/* Define this if your 32-bit syscall API requires 64-bit register
> +   pairs to start with an even-number register.  */
> +#define __ASSUME_ALIGNED_REGISTER_PAIRS  1
> +#endif /* __ILP32__ */

Preprocessor indentation.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

 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 if it doesn't get in by the end of the year.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

 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 if it doesn't get in by the end of the year.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

 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.

[Joseph Myers]

 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.

[Joseph Myers]

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 paramatizable
> 
> Make RTLD_START paramatizable for ILP32 and LP64 usage and provides common
> code between ILP32.
> 
> * sysdeps/aarch64/dl-machine.h (RTLD_START): Rename to ...
> (RTLD_START_1): This and add PTR, PTR_SIZE_LOG, and PTR_SP arguments.
> (RTLD_START): New macro which uses RTLD_START_1.

See what I said in 
 about unified 
ChangeLog stanzas.

Subject

Long description


-mm-dd  Author  

* file: description.
* file2: description.
...

*Not* separate alternating long descriptions and ChangeLog entries.  If 
the changes are logically separable, post them separately.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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.
> (_dl_tlsdesc_undefweak)   : Likewise.

Note this is incorrect ChangeLog formatting.  No spaces before ':' and 
each line should be indented by one TAB.  Please check formatting in all 
patches.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 paramatizable
> 
> Make RTLD_START paramatizable for ILP32 and LP64 usage and provides common
> code between ILP32.
> 
> * sysdeps/aarch64/dl-machine.h (RTLD_START): Rename to ...
> (RTLD_START_1): This and add PTR, PTR_SIZE_LOG, and PTR_SP arguments.
> (RTLD_START): New macro which uses RTLD_START_1.

See what I said in 
 about unified 
ChangeLog stanzas.

Subject

Long description


-mm-dd  Author  

* file: description.
* file2: description.
...

*Not* separate alternating long descriptions and ChangeLog entries.  If 
the changes are logically separable, post them separately.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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.
> (_dl_tlsdesc_undefweak)   : Likewise.

Note this is incorrect ChangeLog formatting.  No spaces before ':' and 
each line should be indented by one TAB.  Please check formatting in all 
patches.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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, R_AARCH64_P32_IRELATIVE): Define.

See what I said in 
.  The patch 
subject and ChangeLog entries seem to have no relation to the patch 
contents.

Before posting any new patch series, please check that every patch 
description is accurate for the patch in question, both the subject line 
and the detailed description, and that you have a unified ChangeLog stanza 
that is also up to date for the change being posted.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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, R_AARCH64_P32_IRELATIVE): Define.

See what I said in 
.  The patch 
subject and ChangeLog entries seem to have no relation to the patch 
contents.

Before posting any new patch series, please check that every patch 
description is accurate for the patch in question, both the subject line 
and the detailed description, and that you have a unified ChangeLog stanza 
that is also up to date for the change being posted.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 other architectures (and AArch64 LP64 - you should test build 
and testsuite for that, as well as ILP32, and confirm that there are no 
testsuite regressions for LP64).

> +/* Copyright (C) 2014 Free Software Foundation, Inc.

See what I said in 
 about 
one-line descriptions before copyright notices.  Please check every new 
file in every patch in the series for this issue.

All copyright notices should have ranges of years that end in 2016.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 other architectures (and AArch64 LP64 - you should test build 
and testsuite for that, as well as ILP32, and confirm that there are no 
testsuite regressions for LP64).

> +/* Copyright (C) 2014 Free Software Foundation, Inc.

See what I said in 
 about 
one-line descriptions before copyright notices.  Please check every new 
file in every patch in the series for this issue.

All copyright notices should have ranges of years that end in 2016.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

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 thoroughly for any message on 
libc-alpha since the first patch series was posted in Oct 2014 that 
relates to AArch64 ILP32 patches (both comments on such patch series, and 
patches other people posted since the 2014 series that build on top of 
it), and make sure that it is addressed.  If you think a comment is 
incorrect, say so explicitly.

> Tested with LTP. Regressions are like this:

As I said in , 
test with the glibc testsuite and report the glibc testsuite results.

-- 
Joseph S. Myers
jos...@codesourcery.com