glibc 2.29: Reminder, only ~3 weeks to freeze!

glibc 2.29: Reminder, only ~3 weeks to freeze!

[Carlos O'Donell]

Community,

This is a reminder that we have only ~3 weeks to the ABI freeze.

January is the month where we stabilize everything.

Feburary 1st is the release for 2.29.

https://sourceware.org/glibc/wiki/Release/2.29

Siddhesh Poyarekar is running the release?
Did I remember that right Siddhesh?

-- 
Cheers,
Carlos.

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Siddhesh Poyarekar]

On 11/12/18 10:18 PM, Carlos O'Donell wrote:
> This is a reminder that we have only ~3 weeks to the ABI freeze.
> 
> January is the month where we stabilize everything.
> 
> Feburary 1st is the release for 2.29.
> 
> https://sourceware.org/glibc/wiki/Release/2.29
> 
> Siddhesh Poyarekar is running the release?
> Did I remember that right Siddhesh?

Sheesh sorry, I am, thanks for covering for me :)

Siddhesh

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Carlos O'Donell]

On 12/11/18 12:16 PM, Siddhesh Poyarekar wrote:
> On 11/12/18 10:18 PM, Carlos O'Donell wrote:
>> This is a reminder that we have only ~3 weeks to the ABI freeze.
>>
>> January is the month where we stabilize everything.
>>
>> Feburary 1st is the release for 2.29.
>>
>> https://sourceware.org/glibc/wiki/Release/2.29
>>
>> Siddhesh Poyarekar is running the release?
>> Did I remember that right Siddhesh?
> 
> Sheesh sorry, I am, thanks for covering for me :)

Honestly, I couldn't remember if anyone had volunteerd :-)

-- 
Cheers,
Carlos.

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[H.J. Lu]

On Tue, Dec 11, 2018 at 8:48 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> Community,
>
> This is a reminder that we have only ~3 weeks to the ABI freeze.
>
> January is the month where we stabilize everything.
>

I'd like to get these in:

https://sourceware.org/ml/libc-alpha/2018-12/msg00399.html
https://sourceware.org/ml/libc-alpha/2018-12/msg00400.html
https://sourceware.org/ml/libc-alpha/2018-12/msg00402.html
https://sourceware.org/ml/libc-alpha/2018-12/msg00401.html


-- 
H.J.

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Siddhesh Poyarekar]

On 12/12/18 1:56 AM, H.J. Lu wrote:
> I'd like to get these in:
> 
> https://sourceware.org/ml/libc-alpha/2018-12/msg00399.html
> https://sourceware.org/ml/libc-alpha/2018-12/msg00400.html
> https://sourceware.org/ml/libc-alpha/2018-12/msg00402.html
> https://sourceware.org/ml/libc-alpha/2018-12/msg00401.html

Please add it to the wiki page as a blocker.

Thanks,
Siddhesh

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Romain Naour]

Hi Carlos, All,

Le 11/12/2018 à 17:48, Carlos O'Donell a écrit :
> Community,
> 
> This is a reminder that we have only ~3 weeks to the ABI freeze.
> 
> January is the month where we stabilize everything.
> 
> Feburary 1st is the release for 2.29.
> 
> https://sourceware.org/glibc/wiki/Release/2.29

I did a test build using glibc [1], binutils 2.31.1, gcc 8.2, kernel-headers
4.14 and gdb 8.1.1 for several architectures [2].

I had a small build issue with gdb <= 8.1 due to commit [3].
The build is fixed by backporting the patch [4] from gdb 8.2 to previous version.

Best regards,
Romain

[1] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
[2] https://gitlab.com/kubu93/toolchains-builder/pipelines/40073241
[3] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
[4]
https://github.com/bminor/binutils-gdb/commit/5a6c3296a7a90694ad4042f6256f3da6d4fa4ee8

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Romain Naour]

Hi All,

Le 13/12/2018 à 23:26, Romain Naour a écrit :
> Hi Carlos, All,
> 
> Le 11/12/2018 à 17:48, Carlos O'Donell a écrit :
>> Community,
>>
>> This is a reminder that we have only ~3 weeks to the ABI freeze.
>>
>> January is the month where we stabilize everything.
>>
>> Feburary 1st is the release for 2.29.
>>
>> https://sourceware.org/glibc/wiki/Release/2.29
> 
> I did a test build using glibc [1], binutils 2.31.1, gcc 8.2, kernel-headers
> 4.14 and gdb 8.1.1 for several architectures [2].
> 
> I had a small build issue with gdb <= 8.1 due to commit [3].
> The build is fixed by backporting the patch [4] from gdb 8.2 to previous version.

Actually there is a regression when the toolchain is built with glibc 2.29 and
gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):

In file included from ../sysdeps/nptl/internaltypes.h:23:0,
                 from ./pthreadP.h:30,
                 from pthread_mutex_getprioceiling.c:21:
pthread_mutex_getprioceiling.c: In function 'pthread_mutex_getprioceiling':
../include/atomic.h:672:4: error: read-only variable '__atg100_val' used as
'asm' output
    __asm ("" : "=r" (__atg100_val) : "0" (*(mem)));         \
    ^
pthread_mutex_getprioceiling.c:29:26: note: in expansion of macro
'atomic_load_relaxed'
   if (__builtin_expect ((atomic_load_relaxed (&(mutex->__data.__kind))
                          ^
The issue has been introduced by:
https://github.com/bminor/glibc/commit/403b4feb22dcbc85ace72a361d2a951380372471

Best regards,
Romain

> 
> Best regards,
> Romain
> 
> [1] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
> [2] https://gitlab.com/kubu93/toolchains-builder/pipelines/40073241
> [3] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
> [4]
> https://github.com/bminor/binutils-gdb/commit/5a6c3296a7a90694ad4042f6256f3da6d4fa4ee8
> 

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Carlos O'Donell]

On 12/14/18 4:04 PM, Romain Naour wrote:
> Hi All,
> 
> Le 13/12/2018 à 23:26, Romain Naour a écrit :
>> Hi Carlos, All,
>>
>> Le 11/12/2018 à 17:48, Carlos O'Donell a écrit :
>>> Community,
>>>
>>> This is a reminder that we have only ~3 weeks to the ABI freeze.
>>>
>>> January is the month where we stabilize everything.
>>>
>>> Feburary 1st is the release for 2.29.
>>>
>>> https://sourceware.org/glibc/wiki/Release/2.29
>>
>> I did a test build using glibc [1], binutils 2.31.1, gcc 8.2, kernel-headers
>> 4.14 and gdb 8.1.1 for several architectures [2].
>>
>> I had a small build issue with gdb <= 8.1 due to commit [3].
>> The build is fixed by backporting the patch [4] from gdb 8.2 to previous version.
> 
> Actually there is a regression when the toolchain is built with glibc 2.29 and
> gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):
> 
> In file included from ../sysdeps/nptl/internaltypes.h:23:0,
>                  from ./pthreadP.h:30,
>                  from pthread_mutex_getprioceiling.c:21:
> pthread_mutex_getprioceiling.c: In function 'pthread_mutex_getprioceiling':
> ../include/atomic.h:672:4: error: read-only variable '__atg100_val' used as
> 'asm' output
>     __asm ("" : "=r" (__atg100_val) : "0" (*(mem)));         \
>     ^
> pthread_mutex_getprioceiling.c:29:26: note: in expansion of macro
> 'atomic_load_relaxed'
>    if (__builtin_expect ((atomic_load_relaxed (&(mutex->__data.__kind))
>                           ^
> The issue has been introduced by:
> https://github.com/bminor/glibc/commit/403b4feb22dcbc85ace72a361d2a951380372471

Can you please file this as a bug against the build component for glibc?

Then please put this on the release blocker list here:
https://sourceware.org/glibc/wiki/Release/2.29

Then I'll poke Stefan about fixing this.

 
> Best regards,
> Romain
> 
>>
>> Best regards,
>> Romain
>>
>> [1] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
>> [2] https://gitlab.com/kubu93/toolchains-builder/pipelines/40073241
>> [3] https://github.com/bminor/glibc/commit/89983cb37c9319806a551e8fe9f3a11ff8f973e1
>> [4]
>> https://github.com/bminor/binutils-gdb/commit/5a6c3296a7a90694ad4042f6256f3da6d4fa4ee8
>>
> 


-- 
Cheers,
Carlos.

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Fri, 14 Dec 2018, Romain Naour wrote:

> Actually there is a regression when the toolchain is built with glibc 2.29 and
> gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):

What platform is this on?

We could consider removing support for building with GCC 4.9; it's more 
than a year since we moved to that as minimum version for building glibc, 
so maybe moving to GCC 5 as a minimum would now make sense.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Romain Naour]

Hi Carlos, Joseph,

Le 14/12/2018 à 22:14, Joseph Myers a écrit :
> On Fri, 14 Dec 2018, Romain Naour wrote:
> 
>> Actually there is a regression when the toolchain is built with glibc 2.29 and
>> gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):
> 
> What platform is this on?

It's on x86 platform.

There is another issue x86_64 with GCC 4.9:

blob_repeat.c:121:3: error: implicit declaration of function
'__builtin_mul_overflow' [-Werror=implicit-function-declaration]
   if (__builtin_mul_overflow (page_size >> common_zeros, element_size,
   ^

> 
> We could consider removing support for building with GCC 4.9; it's more 
> than a year since we moved to that as minimum version for building glibc, 
> so maybe moving to GCC 5 as a minimum would now make sense.
> 

Agree, it seems reasonable.

GCC 4.9 is currently the oldest supported version to build a toolchain with
Buildroot. But I don't think building a glibc 2.29 based toolchain using GCC 4.9
(or older) is a realistic use case.

Best regards,
Romain

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Florian Weimer]

* Romain Naour:

> Hi Carlos, Joseph,
>
> Le 14/12/2018 à 22:14, Joseph Myers a écrit :
>> On Fri, 14 Dec 2018, Romain Naour wrote:
>> 
>>> Actually there is a regression when the toolchain is built with glibc 2.29 and
>>> gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):
>> 
>> What platform is this on?
>
> It's on x86 platform.
>
> There is another issue x86_64 with GCC 4.9:
>
> blob_repeat.c:121:3: error: implicit declaration of function
> '__builtin_mul_overflow' [-Werror=implicit-function-declaration]
>    if (__builtin_mul_overflow (page_size >> common_zeros, element_size,
>    ^

We should fix that because it's been backported to the release
branches.  Please try the patch below.

Thanks,
Florian

-----
Subject: support: Do not require overflow builtin in support/blob_repeat.c

It is only available in GCC 5 and later.

2018-12-15  Florian Weimer  <fweimer@redhat.com>

	* support/blob_repeat.c (check_mul_overflow_size_t): New function.
	(minimum_stride_size): Use it.
	(support_blob_repeat_allocate): Likewise.

diff --git a/support/blob_repeat.c b/support/blob_repeat.c
index 16c1e448b9..718846d81d 100644
--- a/support/blob_repeat.c
+++ b/support/blob_repeat.c
@@ -34,6 +34,26 @@
    optimization because mappings carry a lot of overhead.  */
 static const size_t maximum_small_size = 4 * 1024 * 1024;
 
+/* Set *RESULT to LEFT * RIGHT.  Return true if the multiplication
+   overflowed.  See <malloc/malloc-internal.h>.  */
+static inline bool
+check_mul_overflow_size_t (size_t left, size_t right, size_t *result)
+{
+#if __GNUC__ >= 5
+  return __builtin_mul_overflow (left, right, result);
+#else
+  /* size_t is unsigned so the behavior on overflow is defined.  */
+  *result = left * right;
+  size_t half_size_t = ((size_t) 1) << (8 * sizeof (size_t) / 2);
+  if (__glibc_unlikely ((left | right) >= half_size_t))
+    {
+      if (__glibc_unlikely (right != 0 && *result / right != left))
+        return true;
+    }
+  return false;
+#endif
+}
+
 /* Internal helper for fill.  */
 static void
 fill0 (char *target, const char *element, size_t element_size,
@@ -118,8 +138,8 @@ minimum_stride_size (size_t page_size, size_t element_size)
      common multiple, it appears only once.  Therefore, shift one
      factor.  */
   size_t multiple;
-  if (__builtin_mul_overflow (page_size >> common_zeros, element_size,
-                              &multiple))
+  if (check_mul_overflow_size_t (page_size >> common_zeros, element_size,
+                                 &multiple))
     return 0;
   return multiple;
 }
@@ -255,7 +275,7 @@ support_blob_repeat_allocate (const void *element, size_t element_size,
                               size_t count)
 {
   size_t total_size;
-  if (__builtin_mul_overflow (element_size, count, &total_size))
+  if (check_mul_overflow_size_t (element_size, count, &total_size))
     {
       errno = EOVERFLOW;
       return (struct support_blob_repeat) { 0 };

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Romain Naour]

Hi Florian,

Le 15/12/2018 à 16:23, Florian Weimer a écrit :
> * Romain Naour:
> 
>> Hi Carlos, Joseph,
>>
>> Le 14/12/2018 à 22:14, Joseph Myers a écrit :
>>> On Fri, 14 Dec 2018, Romain Naour wrote:
>>>
>>>> Actually there is a regression when the toolchain is built with glibc 2.29 and
>>>> gcc 4.9 (when USE_ATOMIC_COMPILER_BUILTINS is not defined):
>>>
>>> What platform is this on?
>>
>> It's on x86 platform.
>>
>> There is another issue x86_64 with GCC 4.9:
>>
>> blob_repeat.c:121:3: error: implicit declaration of function
>> '__builtin_mul_overflow' [-Werror=implicit-function-declaration]
>>    if (__builtin_mul_overflow (page_size >> common_zeros, element_size,
>>    ^
> 
> We should fix that because it's been backported to the release
> branches.  Please try the patch below.

Thanks for the patch, it fixes this issue.

Tested-by: Romain Naour <romain.naour@gmail.com>

Best regards,
Romain

> 
> Thanks,
> Florian
> 
> -----
> Subject: support: Do not require overflow builtin in support/blob_repeat.c
> 
> It is only available in GCC 5 and later.
> 
> 2018-12-15  Florian Weimer  <fweimer@redhat.com>
> 
> 	* support/blob_repeat.c (check_mul_overflow_size_t): New function.
> 	(minimum_stride_size): Use it.
> 	(support_blob_repeat_allocate): Likewise.
> 
> diff --git a/support/blob_repeat.c b/support/blob_repeat.c
> index 16c1e448b9..718846d81d 100644
> --- a/support/blob_repeat.c
> +++ b/support/blob_repeat.c
> @@ -34,6 +34,26 @@
>     optimization because mappings carry a lot of overhead.  */
>  static const size_t maximum_small_size = 4 * 1024 * 1024;
>  
> +/* Set *RESULT to LEFT * RIGHT.  Return true if the multiplication
> +   overflowed.  See <malloc/malloc-internal.h>.  */
> +static inline bool
> +check_mul_overflow_size_t (size_t left, size_t right, size_t *result)
> +{
> +#if __GNUC__ >= 5
> +  return __builtin_mul_overflow (left, right, result);
> +#else
> +  /* size_t is unsigned so the behavior on overflow is defined.  */
> +  *result = left * right;
> +  size_t half_size_t = ((size_t) 1) << (8 * sizeof (size_t) / 2);
> +  if (__glibc_unlikely ((left | right) >= half_size_t))
> +    {
> +      if (__glibc_unlikely (right != 0 && *result / right != left))
> +        return true;
> +    }
> +  return false;
> +#endif
> +}
> +
>  /* Internal helper for fill.  */
>  static void
>  fill0 (char *target, const char *element, size_t element_size,
> @@ -118,8 +138,8 @@ minimum_stride_size (size_t page_size, size_t element_size)
>       common multiple, it appears only once.  Therefore, shift one
>       factor.  */
>    size_t multiple;
> -  if (__builtin_mul_overflow (page_size >> common_zeros, element_size,
> -                              &multiple))
> +  if (check_mul_overflow_size_t (page_size >> common_zeros, element_size,
> +                                 &multiple))
>      return 0;
>    return multiple;
>  }
> @@ -255,7 +275,7 @@ support_blob_repeat_allocate (const void *element, size_t element_size,
>                                size_t count)
>  {
>    size_t total_size;
> -  if (__builtin_mul_overflow (element_size, count, &total_size))
> +  if (check_mul_overflow_size_t (element_size, count, &total_size))
>      {
>        errno = EOVERFLOW;
>        return (struct support_blob_repeat) { 0 };
> 

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Albert ARIBAUD]

Hi Carlos,

On Tue, 11 Dec 2018 11:48:39 -0500, Carlos O'Donell <carlos@redhat.com>
wrote :

> Community,
> 
> This is a reminder that we have only ~3 weeks to the ABI freeze.
> 
> January is the month where we stabilize everything.
> 
> Feburary 1st is the release for 2.29.
> 
> https://sourceware.org/glibc/wiki/Release/2.29

Last cycle, inclusion the Y2038 patches was postponed. I would like to
get them in for this release. A first few of them have landed in
already, I can repost the remainder of the series.

Cordialement,
Albert ARIBAUD
3ADEV

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Siddhesh Poyarekar]

On 16/12/18 11:52 PM, Albert ARIBAUD wrote:
> Last cycle, inclusion the Y2038 patches was postponed. I would like to
> get them in for this release. A first few of them have landed in
> already, I can repost the remainder of the series.

Please add it to the wiki when you re-post.

Siddhesh

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Mon, 17 Dec 2018, Siddhesh Poyarekar wrote:

> On 16/12/18 11:52 PM, Albert ARIBAUD wrote:
> > Last cycle, inclusion the Y2038 patches was postponed. I would like to
> > get them in for this release. A first few of them have landed in
> > already, I can repost the remainder of the series.
> 
> Please add it to the wiki when you re-post.

I think it's premature to repost anything involving use of new kernel 
interfaces.  Have the questions of what the kernel will provide for 64-bit 
architectures (regarding new names for old syscall numbers, or new names 
and numbers that are equivalent to old syscalls - and regarding new 
syscalls for the itimerval / rusage cases) been resolved yet?  Once those 
questions have been resolved, I expect we'll need to go through several 
iterations on patches that do no more than define __ASSUME_* macros (with 
very carefully written and reviewed multi-paragraph comments that make 
absolutely clear and unambiguous to readers, who haven't read any of the 
previous discussions, exactly what those macros being defined or undefined 
mean for the different kinds of configurations I list at 
<https://sourceware.org/ml/libc-alpha/2018-09/msg00448.html>), plus a few 
example uses of those macros to help in the review - the review being more 
for getting the right definition of the internal interfaces such as 
__ASSUME_* macros, than for the substance of patches using those 
interfaces.  But those would best be posted when more people are going to 
be around to review them.

If the kernel gets new timespec-based rusage etc. syscalls 
unconditionally, there will also be the question of what glibc bindings 
there should be to such syscalls.  Should such bindings use struct 
timespec as the type in the interface, and so have two versions on systems 
where time_t is currently 32-bit?  Or should they use some timespec-like 
type where the time is always 64-bit, but which is not compatible (in the 
C sense) with struct timespec, so as to have only one version everywhere?  
(And should those bindings have fallback implementations that use the 
existing timeval-based syscalls and convert the data, to work on existing 
kernels.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Sun, 16 Dec 2018, Albert ARIBAUD wrote:

> Last cycle, inclusion the Y2038 patches was postponed. I would like to
> get them in for this release. A first few of them have landed in
> already, I can repost the remainder of the series.

I don't think we can practically get consensus at this time of year on the 
trickier pieces, such as stat functions (cf. Florian's proposal; if we 
eliminate xstat, obviously the new functions with a stat64 variant using 
64-bit times would need to follow), functions involving futexes, or 
anything involving new kernel interfaces.  And obviously there is 
sufficient risk of architecture-specific issues that such changes can't go 
in during the freeze.  For anything using new kernel interfaces, if that 
involves introducing a dependency on new kernel headers to build glibc, 
that would also need to wait for an actual kernel *release* with the new 
features.  For anything involving new structure layouts, we need to be 
especially careful about working out the best choice of layout (should the 
stat64 variant be the same, on all architectures, as Linux uses on 
asm-generic 64-bit systems but with the high part of nanoseconds 
interpreted as padding, for example? - that's not something that will be 
decided by the kernel if the expectation is to use statx syscalls 
everywhere to get stat information with 64-bit times from the kernel).

So while I expect more changes related to more straightforward interfaces 
can go in before 2.29, I don't think we can add _TIME_BITS support or 
export any of the new interfaces from the shared libraries.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Florian Weimer]

* Joseph Myers:

> On Sun, 16 Dec 2018, Albert ARIBAUD wrote:
>
>> Last cycle, inclusion the Y2038 patches was postponed. I would like to
>> get them in for this release. A first few of them have landed in
>> already, I can repost the remainder of the series.
>
> I don't think we can practically get consensus at this time of year on the 
> trickier pieces, such as stat functions (cf. Florian's proposal; if we 
> eliminate xstat, obviously the new functions with a stat64 variant using 
> 64-bit times would need to follow), functions involving futexes, or 
> anything involving new kernel interfaces.

What's a new kernel interface?  Anything that's new to glibc?

Thanks,
Florian

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Tue, 18 Dec 2018, Florian Weimer wrote:

> * Joseph Myers:
> 
> > On Sun, 16 Dec 2018, Albert ARIBAUD wrote:
> >
> >> Last cycle, inclusion the Y2038 patches was postponed. I would like to
> >> get them in for this release. A first few of them have landed in
> >> already, I can repost the remainder of the series.
> >
> > I don't think we can practically get consensus at this time of year on the 
> > trickier pieces, such as stat functions (cf. Florian's proposal; if we 
> > eliminate xstat, obviously the new functions with a stat64 variant using 
> > 64-bit times would need to follow), functions involving futexes, or 
> > anything involving new kernel interfaces.
> 
> What's a new kernel interface?  Anything that's new to glibc?

A new syscall to support 64-bit times on 32-bit systems (or a new ioctl, 
if glibc uses any time-related ioctls).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Florian Weimer]

* Joseph Myers:

> On Tue, 18 Dec 2018, Florian Weimer wrote:
>
>> * Joseph Myers:
>> 
>> > On Sun, 16 Dec 2018, Albert ARIBAUD wrote:
>> >
>> >> Last cycle, inclusion the Y2038 patches was postponed. I would like to
>> >> get them in for this release. A first few of them have landed in
>> >> already, I can repost the remainder of the series.
>> >
>> > I don't think we can practically get consensus at this time of year on the 
>> > trickier pieces, such as stat functions (cf. Florian's proposal; if we 
>> > eliminate xstat, obviously the new functions with a stat64 variant using 
>> > 64-bit times would need to follow), functions involving futexes, or 
>> > anything involving new kernel interfaces.
>> 
>> What's a new kernel interface?  Anything that's new to glibc?
>
> A new syscall to support 64-bit times on 32-bit systems (or a new ioctl, 
> if glibc uses any time-related ioctls).

Okay, so this is not an objection to ABI changes for 2.29.  Thanks.

Florian

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Albert ARIBAUD]

Hi Joseph,

On Mon, 17 Dec 2018 17:53:36 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Sun, 16 Dec 2018, Albert ARIBAUD wrote:
> 
> > Last cycle, inclusion the Y2038 patches was postponed. I would like to
> > get them in for this release. A first few of them have landed in
> > already, I can repost the remainder of the series.  
> 
> I don't think we can practically get consensus at this time of year on the 
> trickier pieces, such as stat functions (cf. Florian's proposal; if we 
> eliminate xstat, obviously the new functions with a stat64 variant using 
> 64-bit times would need to follow), functions involving futexes, or 
> anything involving new kernel interfaces.  And obviously there is 
> sufficient risk of architecture-specific issues that such changes can't go 
> in during the freeze.  For anything using new kernel interfaces, if that 
> involves introducing a dependency on new kernel headers to build glibc, 
> that would also need to wait for an actual kernel *release* with the new 
> features.  For anything involving new structure layouts, we need to be 
> especially careful about working out the best choice of layout (should the 
> stat64 variant be the same, on all architectures, as Linux uses on 
> asm-generic 64-bit systems but with the high part of nanoseconds 
> interpreted as padding, for example? - that's not something that will be 
> decided by the kernel if the expectation is to use statx syscalls 
> everywhere to get stat information with 64-bit times from the kernel).
> 
> So while I expect more changes related to more straightforward interfaces 
> can go in before 2.29, I don't think we can add _TIME_BITS support or 
> export any of the new interfaces from the shared libraries.

I agree we can't start using kernel syscalls or types when these are
not agreed upon yet.

However, we can at least keep converting as much of glibc's internals to
using 64-bit time as possible, even though it would have to convert to
and from 32-bit time at syscall boundaries.

Would such internal changes be OK for 2.29?

(and then  later, once a first official kernel release sports Y2038
syscalls, we'd do a patch series to switch glibc implementations to
using these Y2038 syscalls)

Without syscalls, Y2038 related glibc changes could go as far as
defining a 64-bit struct timespec and struct timeval (their kernel
Y2038 versions are pretty much agreed upon) and switching to using them
internally like we're switching to using __time64_t.

We could even do the same for struct itimerspec, which is basically a
double struct timespec -- there is little risk IMO that the kernel
people might get creative with this one.

Cordialement,
Albert ARIBAUD
3ADEV

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Tue, 18 Dec 2018, Albert ARIBAUD wrote:

> Would such internal changes be OK for 2.29?

If reviewed before 1 January, but you shouldn't really expect much patch 
review to take place in the last couple of weeks in December.

> defining a 64-bit struct timespec and struct timeval (their kernel
> Y2038 versions are pretty much agreed upon) and switching to using them

Is there going to be a new kernel version of struct timeval at all (as 
opposed to the new versions of timeval-using kernel/userspace interfaces 
using the 64-bit version of struct timespec)?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Albert ARIBAUD]

Hi Joseph,

On Tue, 18 Dec 2018 17:33:55 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Tue, 18 Dec 2018, Albert ARIBAUD wrote:
> 
> > Would such internal changes be OK for 2.29?  
> 
> If reviewed before 1 January, but you shouldn't really expect much patch 
> review to take place in the last couple of weeks in December.
> 
> > defining a 64-bit struct timespec and struct timeval (their kernel
> > Y2038 versions are pretty much agreed upon) and switching to using them  
> 
> Is there going to be a new kernel version of struct timeval at all (as 
> opposed to the new versions of timeval-using kernel/userspace interfaces 
> using the 64-bit version of struct timespec)?

Not sure about the kernel indeed.

But what about existing user code which calls public glibc interfaces
which deal with struct timeval? So far there is the assumption that
time-related user source code which compiles with 32-bit time should
compile with 64-bit time without modification. Would we break this and
not "port" existing struct timeval based public interfaces from 32- to
64-bit time?

Cordialement,
Albert ARIBAUD
3ADEV

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Zack Weinberg]

On Tue, Dec 18, 2018 at 2:34 PM Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
>
> But what about existing user code which calls public glibc interfaces
> which deal with struct timeval? So far there is the assumption that
> time-related user source code which compiles with 32-bit time should
> compile with 64-bit time without modification. Would we break this and
> not "port" existing struct timeval based public interfaces from 32- to
> 64-bit time?

I think it would be best to shim as many of the timeval-using APIs as
possible, even if they're obsolescent or even removed in POSIX.  Most
of them should be no problem to shim in user space; the only exception
I can think of, off the top of my head, is setitimer, because its
interaction with execve is different than timer_create+timer_settime.
(Specifically, a CPU time limit installed with
setitimer(ITIMER_VIRTUAL, ...) will survive execve, but if you do the
same thing with timer_create+timer_settime, it won't.)

zw

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers]

On Tue, 18 Dec 2018, Albert ARIBAUD wrote:

> > Is there going to be a new kernel version of struct timeval at all (as 
> > opposed to the new versions of timeval-using kernel/userspace interfaces 
> > using the 64-bit version of struct timespec)?
> 
> Not sure about the kernel indeed.
> 
> But what about existing user code which calls public glibc interfaces
> which deal with struct timeval? So far there is the assumption that

Those get new 64-bit versions as usual.  The question is whether the 
struct timeval for them is purely a userspace choice (because struct 
rusage etc. kernel interfaces get new versions using timespec not timeval) 
or whether it's something to keep in sync with the kernel.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Adhemerval Zanella]

On 11/12/2018 14:48, Carlos O'Donell wrote:
> Community,
> 
> This is a reminder that we have only ~3 weeks to the ABI freeze.
> 
> January is the month where we stabilize everything.
> 
> Feburary 1st is the release for 2.29.
> 
> https://sourceware.org/glibc/wiki/Release/2.29
> 
> Siddhesh Poyarekar is running the release?
> Did I remember that right Siddhesh?
> 

I have updated the wiki with my list:

  * General fixes and refactor for BZ#12683: this is basically to continue
    the long-standing fix for the BZ#12683. I hope I will get everything in
    place to get this done for 2.30.

  * termios refactor: this is a internal cleanup to easier the proposal
    by Hans Peter Anvin to extend termios interface to use newer kernel
    interface and to provide a GNU extension to use higher baud rates.

  * sigaction internal refactor: m68k fixes and some internal cleanup

On desirable points I have added:

  * io: Consolidate lockf implementation.

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Szabolcs Nagy]

On 11/12/2018 16:48, Carlos O'Donell wrote:
> Community,
> 
> This is a reminder that we have only ~3 weeks to the ABI freeze.
> 
> January is the month where we stabilize everything.
> 
> Feburary 1st is the release for 2.29.
> 
> https://sourceware.org/glibc/wiki/Release/2.29

note that sprintf behaviour changed observably such that it
breaks existing code (although not standard conform code).

this may be worth fixing before the release?
https://sourceware.org/ml/libc-alpha/2018-12/msg00634.html

(since it breaks spec2006 and spec2017 and there is no
cmdline flag that allows working this around anybody
who runs spec with glibc will be affected and i think
spec does not fix issues like this.)

Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Siddhesh Poyarekar]

On 11/12/18 10:18 PM, Carlos O'Donell wrote:
> https://sourceware.org/glibc/wiki/Release/2.29

As I had mentioned at Cauldron, I've added the ChangeLog script as a 
release blocker.  There are some specifics that need to be worked out on 
the GNU process front but my understanding is that we have a go-ahead 
from RMS as far as the script is concerned.  There is the contention of 
handling 'all cases' but that could be an ongoing discussion.

I'll get a patch out tomorrow morning so that there's some time this 
week for reviews and then all of the freeze window for stabilization.  I 
will also propose a plan for the transition in my submission.

Siddhesh