Re: Issues building gdbserver with musl

[Rich Felker <dalias@libc.org>]

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