riscv/musl - musl - Gitea: Git with a cup of tea

4588 Commits

2 Branches

78 Tags

7.6 MiB

Tree: d91a6cf6e3

Commit Graph

Author	SHA1	Message	Date
Rich Felker	6ad514e4e2	fix clash between sys/user.h and kernel ptrace.h on powerpc[64], sh due to historical accident/sloppiness in glibc, the powerpc, powerpc64, and sh versions of struct user, defined by sys/user.h, used struct pt_regs from the kernel asm/ptrace.h for their regs member. this made it impossible to define the type in an API-compatible manner without either including asm/ptrace.h like glibc does (contrary to our policy of not depending on kernel headers), or clashing with asm/ptrace.h's definition of struct pt_regs if both headers are included (which is almost always the case in software using sys/user.h). for a long time I viewed this problem as having no reasonable fix. I even explored the possibility of having the powerpc[64] and sh versions of user.h just include the kernel header (breaking with policy), but that looked like it might introduce new clashes with sys/ptrace.h. and it would also bring in a lot of additional cruft that makes no sense for sys/user.h to expose. glibc goes out of its way to suppress some of that with #undef, possibly leading to different problems. this is a rabbit-hole that should be explored no further. as it turns out, however, nothing actually uses struct user sufficiently to care about the type of the regs member; most software including sys/user.h does not even use struct user at all. so, the problem can be fixed just by doing away with the insistence on strict glibc API compatibility for the struct tag of the regs member. rather than renaming the tag, which might lead to the new name entering use as API, simply use an untagged structure inside struct user with the same members/layout as struct pt_regs. for sh, struct pt_dspregs is just removed entirely since it was not used.	7 years ago
Rich Felker	e12fda3bff	add bits/user.h for sh port this seems to have been overlooked, and resulted in breakage in anything including sys/user.h.	12 years ago

Author

SHA1

Message

Date

Rich Felker

6ad514e4e2

fix clash between sys/user.h and kernel ptrace.h on powerpc[64], sh

due to historical accident/sloppiness in glibc, the powerpc,
powerpc64, and sh versions of struct user, defined by sys/user.h, used
struct pt_regs from the kernel asm/ptrace.h for their regs member.
this made it impossible to define the type in an API-compatible manner
without either including asm/ptrace.h like glibc does (contrary to our
policy of not depending on kernel headers), or clashing with
asm/ptrace.h's definition of struct pt_regs if both headers are
included (which is almost always the case in software using
sys/user.h).

for a long time I viewed this problem as having no reasonable fix. I
even explored the possibility of having the powerpc[64] and sh
versions of user.h just include the kernel header (breaking with
policy), but that looked like it might introduce new clashes with
sys/ptrace.h. and it would also bring in a lot of additional cruft
that makes no sense for sys/user.h to expose. glibc goes out of its
way to suppress some of that with #undef, possibly leading to
different problems. this is a rabbit-hole that should be explored no
further.

as it turns out, however, nothing actually uses struct user
sufficiently to care about the type of the regs member; most software
including sys/user.h does not even use struct user at all. so, the
problem can be fixed just by doing away with the insistence on strict
glibc API compatibility for the struct tag of the regs member.

rather than renaming the tag, which might lead to the new name
entering use as API, simply use an untagged structure inside struct
user with the same members/layout as struct pt_regs.

for sh, struct pt_dspregs is just removed entirely since it was not
used.

7 years ago

Rich Felker

e12fda3bff

add bits/user.h for sh port

this seems to have been overlooked, and resulted in breakage in
anything including sys/user.h.

12 years ago

2 Commits (d91a6cf6e369a79587c5665fce9635e5634ca201)