Re: Proposed change to ppc32 ucontext_t

[Paul Mackerras <paulus at samba dot org>]

Ulrich Drepper writes:

> What is the kernel situation?  Is this new code compatible with all kernels?

The kernel situation is that this patch will bring glibc back into
line with the layout historically used by ppc32 kernels (and which has
always been used for 32-bit processes under ppc64 kernels).  The
kernel layout affects SA_SIGINFO signal handlers that use their 3rd
argument, which is declared as void * but is actually a ucontext_t *.
The point of disagreement is the position of the uc_sigmask field.

I had started pushing changes into 2.4 and 2.6.0-test to correspond
with what is currently in glibc CVS.  That change was in 2.4.23-pre2,
pre3 and pre4.  I recently pushed a change to Marcelo to move the
uc_sigmask field back to where it had historically been, and pre5 has
that change.  So all 2.4.xx full releases are compatible with the
patch I sent today.  Basically I have belatedly realized that the
change I was trying to make is really a bad idea and I am trying to
undo most of it, while still retaining the extra space in the
ucontext_t that enables us to implement get/set/make/swapcontext.

In 2.6.0-test, the change to the "new" layout went into BK on 5
September and is in 2.6.0-test5.  I plan to push a changeset to Linus
to move the uc_sigmask back to where it was previously.  In other
words, all 2.5/2.6 releases except for 2.6.0-test5 are compatible with
the patch I sent today.

While we're on the subject, I would appreciate your opinion on whether
we need to do any symbol versioning on get/set/make/swapcontext.  The
situation is that ucontext_t on ppc32 has increased in size - the
previous version didn't have space to store register values, and the
get/set/make/swapcontext routines were non-functional stubs that
simply returned -1 and set errno to ENOSYS.  Do we need to make sure
that programs compiled against older glibc releases continue to get
the non-functional stubs?

Regards,
Paul.