Ian Lance Taylor <i...@golang.org> wrote:
> Sorry, I guess I misread your patch.
No problem, I think this stuff is hard to get right and understand in
general since it is so poorly documented.
> What is the right standalone code for the PPC64 musl case? Thanks.
In order to have the current code (i.e. current gofrontend HEAD with
your patch) compile and work with PPC64 musl it would be sufficient to
just include asm/ptrace.h, as proposed in the v1 of my patch [1]:
// On PowerPC, ucontext.h uses a pt_regs struct as an incomplete
// type. This type must be completed by including asm/ptrace.h.
#ifdef __PPC__
#include <asm/ptrace.h>
#endif
Technically, this should also be needed for using .regs on glibc since
it also declares pt_regs as in incomplete type [5]. As such, adding the
include may be the easiest way to resolve this issue.
However, based on your feedback [2] and feedback by Rich Felker [3]. I
rewrote the go-signal.c PowerPC register handling code to not use .regs
("Having pt_regs appear at all in code not using ptrace is a serious
code smell"). See the v4 of my patch for details [4]. If you don't want
to use .regs on PPC64 musl the right standalone code should be:
((ucontext_t*)(context))->uc_mcontext.gp_regs;
Unfortunately, this code only works on PPC64 musl and PPC64 glibc not on
PPC32 glibc and PPC32 musl, thus I added a case distinction in the v4 of
my patch [4]. For my personal needs it would be very much sufficient to
just add an include of asm/ptrace.h to go-signal.c to make the current
code (i.e. your patch) also work with PPC64 musl.
Greetings,
Sören
[1]: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587520.html
[2]: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590668.html
[3]: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591257.html
[4]: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591593.html
[5]:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/powerpc/sys/ucontext.h;hb=6ff3c7714900529b8f5ca64b58d5da9cd5d5b345#l33
