Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 11 Jun 2017 17:37:20 -0500
From: "A. Wilcox" <>
Subject: Re: Issues building gdbserver with musl

Hash: SHA256

On 10/06/17 21:46, Rich Felker wrote:
> 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.

Have they been contacted to see if they'd be willing to do that?  They
seem to be doing a lot of cleanups and breaking changes in their
current dev cycle, so this would be the time to ask if I'm reading
their lists correctly.

> 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".

Is <sys/user.h> really only used by gdb?  There are no other users?  I
might actually put a #warning or #error in the file when I do the
Adélie mass tree rebuild to see if that really is the only package.
If that is the case, then this really seems like a problem that should
be solved out-of-tree (i.e. with a musl-gdb-support package or similar).

Do you have a list of the so-called "other just for gdb cruft"
headers?  I can put #warning / #error in them too, and we can test the
feasibility of moving these headers out of musl.

> 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.

As you might be able to tell, I am highly motivated to find a way to
fix it :)  That may be because I'm one of a few actually developing
for musl on ppc32...

> Rich

- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
Version: GnuPG v2


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.