public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
@ 2022-01-29  2:37 Andrew Kelley
  2022-01-29  3:00 ` H.J. Lu
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Kelley @ 2022-01-29  2:37 UTC (permalink / raw)
  To: libc-alpha; +Cc: Andrew Kelley

Without this patch, software compiled against glibc 2.34 headers but
then executed on a system with an older glibc version will attempt to
invoke `sysconf(_SC_SIGSTKSZ)` when MINSIGSTKSZ or SIGSTKSZ are used. On
glibcs older than 2.34, this will return -1 (with an errno of EINVAL),
effectively causing MINSIGSTKSZ and SIGSTKSZ to have the value of -1.

This patch version-gates the _DYNAMIC_STACK_SIZE_SOURCE preprocessor
definition so that this problem cannot occur.

Downstream patch:
https://github.com/ziglang/zig/commit/39083c31a550ed80f369f60d35791e98904b8096
---
 include/features.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/features.h b/include/features.h
index ab2b2caac4..77a8f8cc32 100644
--- a/include/features.h
+++ b/include/features.h
@@ -220,8 +220,10 @@
 # define _DEFAULT_SOURCE	1
 # undef  _ATFILE_SOURCE
 # define _ATFILE_SOURCE	1
-# undef  _DYNAMIC_STACK_SIZE_SOURCE
-# define _DYNAMIC_STACK_SIZE_SOURCE 1
+# if __GNUC_PREREQ (2,34)
+#  undef  _DYNAMIC_STACK_SIZE_SOURCE
+#  define _DYNAMIC_STACK_SIZE_SOURCE 1
+# endif
 #endif
 
 /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,
-- 
2.33.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
  2022-01-29  2:37 [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE Andrew Kelley
@ 2022-01-29  3:00 ` H.J. Lu
  2022-01-29  4:04   ` Andrew Kelley
  0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 2022-01-29  3:00 UTC (permalink / raw)
  To: Andrew Kelley; +Cc: GNU C Library

On Fri, Jan 28, 2022 at 6:38 PM Andrew Kelley <andrew@ziglang.org> wrote:
>
> Without this patch, software compiled against glibc 2.34 headers but
> then executed on a system with an older glibc version will attempt to
> invoke `sysconf(_SC_SIGSTKSZ)` when MINSIGSTKSZ or SIGSTKSZ are used. On
> glibcs older than 2.34, this will return -1 (with an errno of EINVAL),
> effectively causing MINSIGSTKSZ and SIGSTKSZ to have the value of -1.
>
> This patch version-gates the _DYNAMIC_STACK_SIZE_SOURCE preprocessor
> definition so that this problem cannot occur.
>
> Downstream patch:
> https://github.com/ziglang/zig/commit/39083c31a550ed80f369f60d35791e98904b8096
> ---
>  include/features.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/features.h b/include/features.h
> index ab2b2caac4..77a8f8cc32 100644
> --- a/include/features.h
> +++ b/include/features.h
> @@ -220,8 +220,10 @@
>  # define _DEFAULT_SOURCE       1
>  # undef  _ATFILE_SOURCE
>  # define _ATFILE_SOURCE        1
> -# undef  _DYNAMIC_STACK_SIZE_SOURCE
> -# define _DYNAMIC_STACK_SIZE_SOURCE 1
> +# if __GNUC_PREREQ (2,34)
> +#  undef  _DYNAMIC_STACK_SIZE_SOURCE
> +#  define _DYNAMIC_STACK_SIZE_SOURCE 1

You are changing a glibc 2.35 header file.   Isn't __GNUC_PREREQ (2,34)
always true? Am I missing something?

> +# endif
>  #endif
>
>  /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,
> --
> 2.33.1
>


-- 
H.J.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
  2022-01-29  3:00 ` H.J. Lu
@ 2022-01-29  4:04   ` Andrew Kelley
  2022-01-29  4:15     ` Andrew Kelley
  2022-02-01 16:37     ` Florian Weimer
  0 siblings, 2 replies; 6+ messages in thread
From: Andrew Kelley @ 2022-01-29  4:04 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 1/28/22 20:00, H.J. Lu wrote:
> On Fri, Jan 28, 2022 at 6:38 PM Andrew Kelley <andrew@ziglang.org> wrote:
>>
>> Without this patch, software compiled against glibc 2.34 headers but
>> then executed on a system with an older glibc version will attempt to
>> invoke `sysconf(_SC_SIGSTKSZ)` when MINSIGSTKSZ or SIGSTKSZ are used. On
>> glibcs older than 2.34, this will return -1 (with an errno of EINVAL),
>> effectively causing MINSIGSTKSZ and SIGSTKSZ to have the value of -1.
>>
>> This patch version-gates the _DYNAMIC_STACK_SIZE_SOURCE preprocessor
>> definition so that this problem cannot occur.
>>
>> Downstream patch:
>> https://github.com/ziglang/zig/commit/39083c31a550ed80f369f60d35791e98904b8096
>> ---
>>   include/features.h | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/features.h b/include/features.h
>> index ab2b2caac4..77a8f8cc32 100644
>> --- a/include/features.h
>> +++ b/include/features.h
>> @@ -220,8 +220,10 @@
>>   # define _DEFAULT_SOURCE       1
>>   # undef  _ATFILE_SOURCE
>>   # define _ATFILE_SOURCE        1
>> -# undef  _DYNAMIC_STACK_SIZE_SOURCE
>> -# define _DYNAMIC_STACK_SIZE_SOURCE 1
>> +# if __GNUC_PREREQ (2,34)
>> +#  undef  _DYNAMIC_STACK_SIZE_SOURCE
>> +#  define _DYNAMIC_STACK_SIZE_SOURCE 1
> 
> You are changing a glibc 2.35 header file.   Isn't __GNUC_PREREQ (2,34)
> always true? Am I missing something?

You are correct.

Downstream we also have a patch that removes the __GLIBC_MINOR__ 
preprocessor definition. Instead, we pass it on the command line.

https://github.com/ziglang/zig/commit/4d48948b526337947ef59a83f7dbc81b70aa5723

The Zig project aims to support targeting many versions of glibc; not 
only the latest one. Our strategy is multi-faceted. For the shared 
objects, there is this project:
https://github.com/ziglang/glibc-abi-tool/

And then we have the headers. For the most part, the latest glibc 
headers are still correct for targeting systems with older glibc 
versions. Some of the other usages of __GNUC_PREREQ look to be 
supporting this use case to me. An occasional patch such as this one is 
needed to make it work correctly, however.

I can understand there would be hesitation to support such a use case. I 
hope that glibc maintainers would consider it however, because 
ultimately it is helping glibc users cross-compile, targeting their 
production systems from their development machines.

Thanks for your time.

> 
>> +# endif
>>   #endif
>>
>>   /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,
>> --
>> 2.33.1
>>
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
  2022-01-29  4:04   ` Andrew Kelley
@ 2022-01-29  4:15     ` Andrew Kelley
  2022-01-29 10:41       ` Szabolcs Nagy
  2022-02-01 16:37     ` Florian Weimer
  1 sibling, 1 reply; 6+ messages in thread
From: Andrew Kelley @ 2022-01-29  4:15 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 1/28/22 21:04, Andrew Kelley wrote:
> On 1/28/22 20:00, H.J. Lu wrote:
>> On Fri, Jan 28, 2022 at 6:38 PM Andrew Kelley <andrew@ziglang.org> wrote:
>>>
>>> Without this patch, software compiled against glibc 2.34 headers but
>>> then executed on a system with an older glibc version will attempt to
>>> invoke `sysconf(_SC_SIGSTKSZ)` when MINSIGSTKSZ or SIGSTKSZ are used. On
>>> glibcs older than 2.34, this will return -1 (with an errno of EINVAL),
>>> effectively causing MINSIGSTKSZ and SIGSTKSZ to have the value of -1.
>>>
>>> This patch version-gates the _DYNAMIC_STACK_SIZE_SOURCE preprocessor
>>> definition so that this problem cannot occur.
>>>
>>> Downstream patch:
>>> https://github.com/ziglang/zig/commit/39083c31a550ed80f369f60d35791e98904b8096 
>>>
>>> ---
>>>   include/features.h | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/features.h b/include/features.h
>>> index ab2b2caac4..77a8f8cc32 100644
>>> --- a/include/features.h
>>> +++ b/include/features.h
>>> @@ -220,8 +220,10 @@
>>>   # define _DEFAULT_SOURCE       1
>>>   # undef  _ATFILE_SOURCE
>>>   # define _ATFILE_SOURCE        1
>>> -# undef  _DYNAMIC_STACK_SIZE_SOURCE
>>> -# define _DYNAMIC_STACK_SIZE_SOURCE 1
>>> +# if __GNUC_PREREQ (2,34)
>>> +#  undef  _DYNAMIC_STACK_SIZE_SOURCE
>>> +#  define _DYNAMIC_STACK_SIZE_SOURCE 1
>>
>> You are changing a glibc 2.35 header file.   Isn't __GNUC_PREREQ (2,34)
>> always true? Am I missing something?
> 
> You are correct.
> 
> Downstream we also have a patch that removes the __GLIBC_MINOR__ 
> preprocessor definition. Instead, we pass it on the command line.
> 
> https://github.com/ziglang/zig/commit/4d48948b526337947ef59a83f7dbc81b70aa5723 
> 
> 
> The Zig project aims to support targeting many versions of glibc; not 
> only the latest one. Our strategy is multi-faceted. For the shared 
> objects, there is this project:
> https://github.com/ziglang/glibc-abi-tool/
> 
> And then we have the headers. For the most part, the latest glibc 
> headers are still correct for targeting systems with older glibc 
> versions. Some of the other usages of __GNUC_PREREQ look to be 
> supporting this use case to me. An occasional patch such as this one is 
> needed to make it work correctly, however.
> 
> I can understand there would be hesitation to support such a use case. I 
> hope that glibc maintainers would consider it however, because 
> ultimately it is helping glibc users cross-compile, targeting their 
> production systems from their development machines.
> 
> Thanks for your time.


I just noticed that, while the downstream patch that I linked has the 
correct improvement, I bungled the upstream patch here because I 
misunderstood what __GNUC_PREREQ does. This is the actual patch that I 
am proposing:

--- a/include/features.h
+++ b/include/features.h
@@ -220,8 +220,10 @@
  # define _DEFAULT_SOURCE       1
  # undef  _ATFILE_SOURCE
  # define _ATFILE_SOURCE        1
-# undef  _DYNAMIC_STACK_SIZE_SOURCE
-# define _DYNAMIC_STACK_SIZE_SOURCE 1
+# if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 34) || __GLIBC__ > 2
+#  undef  _DYNAMIC_STACK_SIZE_SOURCE
+#  define _DYNAMIC_STACK_SIZE_SOURCE 1
+# endif
  #endif

  /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
  2022-01-29  4:15     ` Andrew Kelley
@ 2022-01-29 10:41       ` Szabolcs Nagy
  0 siblings, 0 replies; 6+ messages in thread
From: Szabolcs Nagy @ 2022-01-29 10:41 UTC (permalink / raw)
  To: Andrew Kelley; +Cc: H.J. Lu, GNU C Library

* Andrew Kelley <andrew@ziglang.org> [2022-01-28 21:15:36 -0700]:
> On 1/28/22 21:04, Andrew Kelley wrote:
> > Downstream we also have a patch that removes the __GLIBC_MINOR__
> > preprocessor definition. Instead, we pass it on the command line.
> > 
> > https://github.com/ziglang/zig/commit/4d48948b526337947ef59a83f7dbc81b70aa5723
> > 
> > 
> > The Zig project aims to support targeting many versions of glibc; not
> > only the latest one. Our strategy is multi-faceted. For the shared
> > objects, there is this project:
> > https://github.com/ziglang/glibc-abi-tool/
> > 
> > And then we have the headers. For the most part, the latest glibc
> > headers are still correct for targeting systems with older glibc

new headers may rely on new symbols, behaviours and abi that
did not exist in an old glibc.

the only way multiple glibc versions are supported at runtime
is to compile against old glibc and run the binary against a
newer one. not the other way around.

and you cannot detect at compile time what will be the glibc
version at runtime, so version checking does not help.
what problem are you solving by passing __GLIBC_MINOR__ at
compile time?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
  2022-01-29  4:04   ` Andrew Kelley
  2022-01-29  4:15     ` Andrew Kelley
@ 2022-02-01 16:37     ` Florian Weimer
  1 sibling, 0 replies; 6+ messages in thread
From: Florian Weimer @ 2022-02-01 16:37 UTC (permalink / raw)
  To: Andrew Kelley; +Cc: H.J. Lu, GNU C Library

* Andrew Kelley:

> The Zig project aims to support targeting many versions of glibc; not
> only the latest one. Our strategy is multi-faceted. For the shared 
> objects, there is this project:
> https://github.com/ziglang/glibc-abi-tool/
>
> And then we have the headers. For the most part, the latest glibc
> headers are still correct for targeting systems with older glibc 
> versions. Some of the other usages of __GNUC_PREREQ look to be
> supporting this use case to me. An occasional patch such as this one
> is needed to make it work correctly, however.

__GNUC_PREREQ certainly does not work for this, it's for GCC version
checks.

Why do you need *C* header files?

Thanks,
Florian


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-02-01 16:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-29  2:37 [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE Andrew Kelley
2022-01-29  3:00 ` H.J. Lu
2022-01-29  4:04   ` Andrew Kelley
2022-01-29  4:15     ` Andrew Kelley
2022-01-29 10:41       ` Szabolcs Nagy
2022-02-01 16:37     ` Florian Weimer

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