Re: Discussion about why GNU/Linux system upgrades cause old programs to break

Richard Stallman <[email protected]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Incidentally, I went to compile Emacs 27.2 on modern glibc and found
>   > that there was, in fact, a real breakage: SIGSTKSZ on GNU/Linux is not a
>   > constant expression anymore (seemingly because some CPUs have started
>   > requiring varying sizes of stacks to save register pages), if
>   > _DYNAMIC_STACK_SIZE_SOURCE, which is enabled with _GNU_SOURCE.
>
> This seems to call for deeper thinking.
>
> 1. What is a "register page", and how does this save some of them?

Here I use it to mean the set of registers the CPU offers.  These must
be saved to memory (usually, some stack memory) on context switches and
signal delivery, so that programs can return back to their work after
the signal handler/context switch is done.

> 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

Without it (i.e. compiling without extensions):

  ~$ gcc -E -dM -include signal.h -x c /dev/null -o - | grep ' SIGSTKSZ'
  #define SIGSTKSZ 8192
  ~$

The latter is in line with POSIX.

> 4. Could changes in defaults for macros such as
> _DYNAMIC_STACK_SIZE_SOURCE and _GNU_SOURCE fix this problem?
> Or the definition of a new macro of that kind?

I'm not sure what you mean.

There isn't really a fix for this issue other than introducing the break
that was introduced.

One could argue that the break could've been introduced more gently, by,
for instance, emitting a warning when the constant is used for some
period of time.

There's precedent for doing so, of course.  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), and because the value it was defined to was already
insufficient on some architectures at the time when the change occurred.

The break happened because some CPU architectures are still evolving,
thus assuming any static stack size could, in the future, mean that you
assumed wrong.

Of course, we could, say, reserve 64K and presume that no CPU could ever
possibly have more than 64K worth of registers.

But, could it not?  AMD GPUs, for instance, provide 512 vector registers
of 64 lanes of 32 bits each.  That's already 128K, and that's not all
the registers those GPUs have.

Naturally, those are a bit of a special case, but I hope it demonstrates
the problem anyway.
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmp8sQgbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJMx
VQD/Z2Rg432kKwqjL2mUmj6gSV6ob+eq2OpgLihezfcAxzMA+waV8BxixvhZFCru
lUNfP9yglz7tXyhmtfzxMRuQH3oB
=QP3X
-----END PGP SIGNATURE-----