|
Message-ID: <20170611024616.GW1627@brightrain.aerifal.cx> Date: Sat, 10 Jun 2017 22:46:16 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Issues building gdbserver with musl On Mon, Jun 05, 2017 at 11:31:27AM +0200, Thomas Petazzoni wrote: > Hello, > > On Sat, 3 Jun 2017 18:50:59 -0400, mzpqnxow wrote: > > FWIW, the following is the patch I came up with for PPC- it was very, very > > short: > > > > diff -Naur gdb-7.12/gdb/gdbserver/linux-ppc-low.c > > gdb-7.12-ppc-patched/gdb/gdbserver/linux-ppc-low.c > > --- gdb-7.12/gdb/gdbserver/linux-ppc-low.c 2016-08-01 11:50:20.000000000 > > -0400 > > +++ gdb-7.12-ppc-patched/gdb/gdbserver/linux-ppc-low.c 2017-05-15 > > 13:40:22.073884258 -0400 > > @@ -21,7 +21,9 @@ > > #include "linux-low.h" > > > > #include <elf.h> > > +#define __ASSEMBLY__ > > #include <asm/ptrace.h> > > +#undef __ASSEMBLY__ > > Can we upstream something like this? What is the explanation why musl > needs such a patch and not glibc/uclibc? Sorry for the delayed response. The reason is a historical mess. The original intent of glibc was not to use kernel headers to define things the libc headers need to provide, but to do their own definitions for everything (like musl always does). But some poorly maintained archs (that were originally maintained out-of-tree) ignored this rule/intent and did things the old (libc5) way, using the kernel headers. In order to provide an API matching what glibc exposes, musl defines pt_regs etc. in the powerpc sys/user.h. (Compare this to something like the arm version, which has non-overlapping names.) But this breaks if you also include the kernel header that defines pt_regs. I'm not sure what the right solution is; there really is no good one. Ideally musl and glibc would agree the problem needs to be fixed and change user.h to provide definitions with new names that don't clash with the kernel, and fix glibc's use of kernel headers. But then applications (basically just gdb) would need to be fixed to use the new names. Another possible solution would be removing sys/user.h and other "just for gdb cruft" from musl and providing it in a separate package that depends (for some archs) on kernel headers. Or we could do something really nasty and just say "on broken archs X, Y, and Z, sys/user.h and other cruft headers depend on kernel headers, just like on glibc". I'm not really sure what's best to do; that's why there's been no progress on this issue, despite it being known and longstanding. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.