Bug#207806: libc6-dev: [ppc] source code compatibility broken 2.3.1->2.3.2
On Wed, Sep 10, 2003 at 06:29:39PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 29, 2003 at 10:38:09AM +0100, Christophe Rhodes wrote:
> > Package: libc6-dev
> > Version: 2.3.1-17
> > Severity: important
> >
> > This isn't about the platform or version of libc6-dev generated by
> > reportbug, sorry, but about 2.3.2 on ppc.
> >
> > The definition of ucontext_t and mcontext_t changed for powerpc32
> > systems between 2.3.1 and 2.3.2. They did so in a source-code
> > incompatible way, such that programs of the form
> >
> > #include <stdlib.h>
> > #include <signal.h>
> > #include <sys/types.h>
> > #include <sys/ucontext.h>
> > #include <unistd.h>
> >
> > void sigsegv_handler(int sig, siginfo_t *info, void *context) {
> > printf("PC = %x", (((ucontext_t *) context)->uc_mcontext.regs)->nip);
> > }
> >
> > int main() {
> > struct sigaction sa;
> > pid_t pid;
> > sa.sa_sigaction = sigsegv_handler;
> > sa.sa_flags = SA_SIGINFO | SA_RESTART;
> > sigaction(SIGSEGV, $sa, NULL);
> >
> > pid = getpid();
> > kill(pid, SIGSEGV);
> > }
> >
> > no longer compile, let alone run, because the mcontext_t structure no
> > longer has an element "regs".
> >
> > Furthermore, the new definition does not agree with what the kernel
> > passes to signal handlers. If I were to adjust the source code to use
> > the new uc_mcontext structure slot and definition, I would end up with
> > garbage in my signal handler, because the kernel does not put any
> > information where libc has placed uc_mcontext. It _does_ put some in
> > the "for backwards compatibility" area, so I can get at the information
> > using the uc_regs and uc_oldsigmask slots, but I can't see how this
> > change has helped anyone.
> >
> > It may be worth mentioning Debian bug #157374, where much the same
> > problem (on hppa and mips) was discussed and fixed. The bottom line is
> > that the C library and the kernel's definition of a ucontext and an
> > mcontext must agree.
>
> This appears to be, unfortunately, necessary.
>
> The missing item in your research is that Linux 2.6 now (just now)
> passes the information in the new format. Not all of the registers
> which were necessary actually fit inside the old definition. It had to
> change.
>
> The fact that they broke source compatibility is a bit annoying. And
> there's no good flag that you need the new kernel in order to use the
> new interface. Complain to libc-alpha and Paul/Steve if you want. Paul
> tells me that binary compatibility should continue to work, and that
> seems to be true, via the uc_regs pointer.
However, breaking source compatibility was not necessary. I'm
discussing this with the kernel maintainer (Paul) now.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: