Bug#207806: libc6-dev: [ppc] source code compatibility broken 2.3.1->2.3.2
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: