* glibc 2.29: Reminder, only ~3 weeks to freeze!
@ 2018-12-11 17:12 Carlos O'Donell
2018-12-11 17:18 ` Siddhesh Poyarekar
` (6 more replies)
0 siblings, 7 replies; 27+ messages in thread
From: Carlos O'Donell @ 2018-12-11 17:12 UTC (permalink / raw)
To: GNU C Library, Siddhesh Poyarekar
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
@ 2018-12-11 17:18 ` Siddhesh Poyarekar
2018-12-11 20:24 ` Carlos O'Donell
2018-12-11 21:22 ` H.J. Lu
` (5 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: Siddhesh Poyarekar @ 2018-12-11 17:18 UTC (permalink / raw)
To: Carlos O'Donell, GNU C Library
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:18 ` Siddhesh Poyarekar
@ 2018-12-11 20:24 ` Carlos O'Donell
0 siblings, 0 replies; 27+ messages in thread
From: Carlos O'Donell @ 2018-12-11 20:24 UTC (permalink / raw)
To: Siddhesh Poyarekar, GNU C Library
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
2018-12-11 17:18 ` Siddhesh Poyarekar
@ 2018-12-11 21:22 ` H.J. Lu
2018-12-12 12:59 ` Siddhesh Poyarekar
2018-12-13 22:35 ` Romain Naour
` (4 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2018-12-11 21:22 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: GNU C Library, Siddhesh Poyarekar
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 21:22 ` H.J. Lu
@ 2018-12-12 12:59 ` Siddhesh Poyarekar
0 siblings, 0 replies; 27+ messages in thread
From: Siddhesh Poyarekar @ 2018-12-12 12:59 UTC (permalink / raw)
To: H.J. Lu, Carlos O'Donell; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
2018-12-11 17:18 ` Siddhesh Poyarekar
2018-12-11 21:22 ` H.J. Lu
@ 2018-12-13 22:35 ` Romain Naour
2018-12-14 21:08 ` Romain Naour
2018-12-16 18:51 ` Albert ARIBAUD
` (3 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: Romain Naour @ 2018-12-13 22:35 UTC (permalink / raw)
To: Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-13 22:35 ` Romain Naour
@ 2018-12-14 21:08 ` Romain Naour
2018-12-14 21:14 ` Carlos O'Donell
2018-12-14 21:15 ` Joseph Myers
0 siblings, 2 replies; 27+ messages in thread
From: Romain Naour @ 2018-12-14 21:08 UTC (permalink / raw)
To: Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
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
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-14 21:08 ` Romain Naour
@ 2018-12-14 21:14 ` Carlos O'Donell
2018-12-14 21:15 ` Joseph Myers
1 sibling, 0 replies; 27+ messages in thread
From: Carlos O'Donell @ 2018-12-14 21:14 UTC (permalink / raw)
To: Romain Naour, GNU C Library, Siddhesh Poyarekar
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-14 21:08 ` Romain Naour
2018-12-14 21:14 ` Carlos O'Donell
@ 2018-12-14 21:15 ` Joseph Myers
2018-12-14 22:32 ` Romain Naour
1 sibling, 1 reply; 27+ messages in thread
From: Joseph Myers @ 2018-12-14 21:15 UTC (permalink / raw)
To: Romain Naour; +Cc: Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-14 21:15 ` Joseph Myers
@ 2018-12-14 22:32 ` Romain Naour
2018-12-15 17:56 ` Florian Weimer
0 siblings, 1 reply; 27+ messages in thread
From: Romain Naour @ 2018-12-14 22:32 UTC (permalink / raw)
To: Joseph Myers; +Cc: Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-14 22:32 ` Romain Naour
@ 2018-12-15 17:56 ` Florian Weimer
2018-12-16 15:11 ` Romain Naour
0 siblings, 1 reply; 27+ messages in thread
From: Florian Weimer @ 2018-12-15 17:56 UTC (permalink / raw)
To: Romain Naour
Cc: Joseph Myers, Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
* 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 };
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-15 17:56 ` Florian Weimer
@ 2018-12-16 15:11 ` Romain Naour
0 siblings, 0 replies; 27+ messages in thread
From: Romain Naour @ 2018-12-16 15:11 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Carlos O'Donell, GNU C Library, Siddhesh Poyarekar
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 };
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
` (2 preceding siblings ...)
2018-12-13 22:35 ` Romain Naour
@ 2018-12-16 18:51 ` Albert ARIBAUD
2018-12-17 9:18 ` Siddhesh Poyarekar
2018-12-17 18:11 ` Joseph Myers
2018-12-17 19:44 ` Adhemerval Zanella
` (2 subsequent siblings)
6 siblings, 2 replies; 27+ messages in thread
From: Albert ARIBAUD @ 2018-12-16 18:51 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-16 18:51 ` Albert ARIBAUD
@ 2018-12-17 9:18 ` Siddhesh Poyarekar
2018-12-17 18:16 ` Joseph Myers
2018-12-17 18:11 ` Joseph Myers
1 sibling, 1 reply; 27+ messages in thread
From: Siddhesh Poyarekar @ 2018-12-17 9:18 UTC (permalink / raw)
To: Albert ARIBAUD, Carlos O'Donell; +Cc: GNU C Libraryt
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-16 18:51 ` Albert ARIBAUD
2018-12-17 9:18 ` Siddhesh Poyarekar
@ 2018-12-17 18:11 ` Joseph Myers
2018-12-18 9:26 ` Florian Weimer
2018-12-18 16:51 ` Albert ARIBAUD
1 sibling, 2 replies; 27+ messages in thread
From: Joseph Myers @ 2018-12-17 18:11 UTC (permalink / raw)
To: Albert ARIBAUD; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-17 9:18 ` Siddhesh Poyarekar
@ 2018-12-17 18:16 ` Joseph Myers
0 siblings, 0 replies; 27+ messages in thread
From: Joseph Myers @ 2018-12-17 18:16 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: Albert ARIBAUD, Carlos O'Donell, GNU C Libraryt
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
` (3 preceding siblings ...)
2018-12-16 18:51 ` Albert ARIBAUD
@ 2018-12-17 19:44 ` Adhemerval Zanella
2018-12-18 16:53 ` Szabolcs Nagy
2018-12-18 17:18 ` Siddhesh Poyarekar
6 siblings, 0 replies; 27+ messages in thread
From: Adhemerval Zanella @ 2018-12-17 19:44 UTC (permalink / raw)
To: libc-alpha
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-17 18:11 ` Joseph Myers
@ 2018-12-18 9:26 ` Florian Weimer
2018-12-18 13:44 ` Joseph Myers
2018-12-18 16:51 ` Albert ARIBAUD
1 sibling, 1 reply; 27+ messages in thread
From: Florian Weimer @ 2018-12-18 9:26 UTC (permalink / raw)
To: Joseph Myers; +Cc: Albert ARIBAUD, libc-alpha
* 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 9:26 ` Florian Weimer
@ 2018-12-18 13:44 ` Joseph Myers
2018-12-18 16:23 ` Florian Weimer
0 siblings, 1 reply; 27+ messages in thread
From: Joseph Myers @ 2018-12-18 13:44 UTC (permalink / raw)
To: Florian Weimer; +Cc: Albert ARIBAUD, libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 13:44 ` Joseph Myers
@ 2018-12-18 16:23 ` Florian Weimer
0 siblings, 0 replies; 27+ messages in thread
From: Florian Weimer @ 2018-12-18 16:23 UTC (permalink / raw)
To: Joseph Myers; +Cc: Albert ARIBAUD, libc-alpha
* 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-17 18:11 ` Joseph Myers
2018-12-18 9:26 ` Florian Weimer
@ 2018-12-18 16:51 ` Albert ARIBAUD
2018-12-18 17:42 ` Joseph Myers
1 sibling, 1 reply; 27+ messages in thread
From: Albert ARIBAUD @ 2018-12-18 16:51 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
` (4 preceding siblings ...)
2018-12-17 19:44 ` Adhemerval Zanella
@ 2018-12-18 16:53 ` Szabolcs Nagy
2018-12-18 17:18 ` Siddhesh Poyarekar
6 siblings, 0 replies; 27+ messages in thread
From: Szabolcs Nagy @ 2018-12-18 16:53 UTC (permalink / raw)
To: Carlos O'Donell, GNU C Library, Siddhesh Poyarekar; +Cc: nd
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.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
` (5 preceding siblings ...)
2018-12-18 16:53 ` Szabolcs Nagy
@ 2018-12-18 17:18 ` Siddhesh Poyarekar
6 siblings, 0 replies; 27+ messages in thread
From: Siddhesh Poyarekar @ 2018-12-18 17:18 UTC (permalink / raw)
To: Carlos O'Donell, GNU C Library
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 16:51 ` Albert ARIBAUD
@ 2018-12-18 17:42 ` Joseph Myers
2018-12-18 19:57 ` Albert ARIBAUD
0 siblings, 1 reply; 27+ messages in thread
From: Joseph Myers @ 2018-12-18 17:42 UTC (permalink / raw)
To: Albert ARIBAUD; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 17:42 ` Joseph Myers
@ 2018-12-18 19:57 ` Albert ARIBAUD
2018-12-18 21:04 ` Zack Weinberg
2018-12-18 22:52 ` Joseph Myers
0 siblings, 2 replies; 27+ messages in thread
From: Albert ARIBAUD @ 2018-12-18 19:57 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 19:57 ` Albert ARIBAUD
@ 2018-12-18 21:04 ` Zack Weinberg
2018-12-18 22:52 ` Joseph Myers
1 sibling, 0 replies; 27+ messages in thread
From: Zack Weinberg @ 2018-12-18 21:04 UTC (permalink / raw)
To: Albert ARIBAUD; +Cc: Joseph Myers, GNU C Library
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: glibc 2.29: Reminder, only ~3 weeks to freeze!
2018-12-18 19:57 ` Albert ARIBAUD
2018-12-18 21:04 ` Zack Weinberg
@ 2018-12-18 22:52 ` Joseph Myers
1 sibling, 0 replies; 27+ messages in thread
From: Joseph Myers @ 2018-12-18 22:52 UTC (permalink / raw)
To: Albert ARIBAUD; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2018-12-18 22:41 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-11 17:12 glibc 2.29: Reminder, only ~3 weeks to freeze! Carlos O'Donell
2018-12-11 17:18 ` Siddhesh Poyarekar
2018-12-11 20:24 ` Carlos O'Donell
2018-12-11 21:22 ` H.J. Lu
2018-12-12 12:59 ` Siddhesh Poyarekar
2018-12-13 22:35 ` Romain Naour
2018-12-14 21:08 ` Romain Naour
2018-12-14 21:14 ` Carlos O'Donell
2018-12-14 21:15 ` Joseph Myers
2018-12-14 22:32 ` Romain Naour
2018-12-15 17:56 ` Florian Weimer
2018-12-16 15:11 ` Romain Naour
2018-12-16 18:51 ` Albert ARIBAUD
2018-12-17 9:18 ` Siddhesh Poyarekar
2018-12-17 18:16 ` Joseph Myers
2018-12-17 18:11 ` Joseph Myers
2018-12-18 9:26 ` Florian Weimer
2018-12-18 13:44 ` Joseph Myers
2018-12-18 16:23 ` Florian Weimer
2018-12-18 16:51 ` Albert ARIBAUD
2018-12-18 17:42 ` Joseph Myers
2018-12-18 19:57 ` Albert ARIBAUD
2018-12-18 21:04 ` Zack Weinberg
2018-12-18 22:52 ` Joseph Myers
2018-12-17 19:44 ` Adhemerval Zanella
2018-12-18 16:53 ` Szabolcs Nagy
2018-12-18 17:18 ` Siddhesh Poyarekar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).