Re: Discussion about why GNU/Linux system upgrades cause old programs to break
Arsen Arsenović <[email protected]>
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
Richard Stallman <[email protected]> writes: > > > 2. "SIGSTKSZ on GNU/Linux is not a constant expression any more": does > > > that mean (1) SIGSTKSZ _may_ not be a constant, if the architecture in > > > use requires varying sizes of stacks, or (2) SIGSTKSZ is _never_ a > > > constant, on any architecture, whether it actually can vary or not? > > > It seems that it was made non-constant for all arches, even those that > > won't vary in the future. > > > > 3. What is the latest GCC definition of SIGSTKSZ on the x86_64 architecture? > > > With _DYNAMIC_STACK_SIZE_SOURCE (and, thus, also with _GNU_SOURCE): > > > ~$ gcc -E -dM -include signal.h -x c /dev/null -o - -D_DYNAMIC_STACK_SIZE_SOURCE | grep ' SIGSTKSZ' > > #define SIGSTKSZ sysconf (_SC_SIGSTKSZ) > > #define MINSIGSTKSZ SIGSTKSZ > > I see the issue now. Thanks for explaining it. > > SIGSTKSZ is a very obscure feature, so I think it will be rare that > old user programs refer to it at all. But... > > I presume it wasn't done in > > this case because SIGSTKSZ has fairly few users (only 4.7K instances > > over all of Debian, among which is Emacs; note that not all of those > > uses will break), > > I'm surprised -- 5000 uses seems surprisingly many to me. Are most of > those uses in the Linux sources? It would be used a lot there. > > For curiosity, can you show us the list of programs in Debian that > refer to SIGSTKSZ? I wonder how many ordinary user programs refer to > it. The matches includes various redundancies, and the libc itself, and the kernel. You can see the full list here: https://codesearch.debian.net/search?q=SIGSTKSZ&literal=1 (requires JS, though presumably only free JS). This will match any line containing the term "SIGSTKSZ", thus also MINSIGSTKSZ and MY_UNRELATED_THING_THAT_CONTAINS_SIGSTKSZ. The full list of packages is available here: https://codesearch.debian.net/results/30c83086d81599b0/packages.txt (the code search tool generates one such page for each search; the above was generated for my search using the query in the previous paragraph, and the link may expire. I do not know how long they live.) From a quick skim, the list seems to be inflated a lot by Rust packages, which host a copy of such constants for each platform they can run on, for each package (due to the way Rust programs carry dependencies). Excluding those, the list goes down to 2261 matches (!). 111 matches appear to be in glibc. There appear to be a few more libcs in the repository. Golang also seems to host a fair few, with reasoning similar to Rust probably. Excluding those, we're left with 1712 results; final query I landed on: SIGSTKSZ -path:.*\.rs -path:.*\.go -package:glibc -package:golang-modernc-libc -package:.*libc I wish I could download the full list of matches with context windows to examine and classify them faster than I can in a browser, but I don't see a way to do that at the moment, unfortunately. For reference, searching for: sigaction|signal\s*\( (i.e. calls to 'signal' or 'sigaction') yields 161545 matches. -- Arsen Arsenović
signature.asc
(application/pgp-signature, 418 B)
-----BEGIN PGP SIGNATURE----- iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmqAr64bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJMQ kwEA5ABgf7bk/zWLtXGRq5EtgMB9H5TdBmwTZ4aEIzHRJOUA/0ura904qwJGuTy4 u0xsphp2YQjeUcix+e9OLB+W0mMP =3ng9 -----END PGP SIGNATURE-----