Is it suitable to replace risc-v sigcontext.h with generic sigcontext.h in gilbc?

[Vincent Chen]

Hi folks:
I have a question about the RISC-V Glibc sigcontext.h file. Before
asking the question, I quickly introduce the usage of sigcontext.h. If
you are familiar with it, you can skip it and go to the 2nd paragraph.
Linux kernel used the struct sigcontext defined in kernel's
sigcontext.h to create the context for signal handling. The program in
user space also can use the struct sigcontext defined in Glibc
sigcontext.h to access this context in the signal handler. Because the
contents of the 2 struct sigcontext are the same in most
architectures, so the Glibc generic sigcontext.h just includes the
asm/sigcontext.h from kernel instead of defining a new struct
sigcontext. Most architectures such as AARCH64 and PowerPC use generic
sigcontext.h to avoid doing synchronization between Glibc's and
kernel's sigcontext.h.
However, in the current RISC-V Glibc ports, I found that RISC-V
Glibc creates a sigcontext.h in sysdeps/unix/sysv/linux/riscv/bits/
folder instead of leveraging the Glibc generic sigcontext.h. In this
self-created sigcontext.h, a new struct sigcontext is defined. This
struct sigcontext has the same memory layout as the kernel struct
sigcontext, but the members' names are different from the kernel. It
causes that we need to synchronize the contents of the struct
sigcontext in Glibc whenever the struct sigcontext in kernel changs.
Taking V extension support as an example, the vector registers are
parts of the signal context. Therefore, after completing the kernel
ports, we need to do the same modification for struct sigcontext in
Glibc. This may be a bit inconvenient. Hence, I think if the current
implementation of Glibc riscv sigcontext.h is not for some reason,
could we replace this self-defined sigcontext.h with the generic
sigcontext.h? I know this may cause some Glibc backward compatible
issues, but it really reduces the possibility of inconsistencies
between these two files and saves synchronization work. Any feedback
is welcome, I sincerely appreciate any time or comment made.

By the way, I have used the Glibc test suite to test the modification
(using the generic sigcontext.h) on QEMU, and it works well.

Best regards,
Vincent

[Jim Wilson]

On Wed, Jun 10, 2020 at 12:40 AM Vincent Chen <vincen...@sifive.com> wrote:
> Glibc. This may be a bit inconvenient. Hence, I think if the current
> implementation of Glibc riscv sigcontext.h is not for some reason,
> could we replace this self-defined sigcontext.h with the generic
> sigcontext.h? I know this may cause some Glibc backward compatible
> issues, but it really reduces the possibility of inconsistencies
> between these two files and saves synchronization work. Any feedback
> is welcome, I sincerely appreciate any time or comment made.

If you change the field names and types, then this will break programs
that use the sigcontext structure. In gcc for instance,
libgcc/config/riscv/linux-unwind.h uses sigcontext, and accesses the
gregs field. This is for doing stack unwinding (e.g. C++ exception
handling) from a signal handler frame. We can fix gcc if sigcontext
changes, but then new gcc sources won't build with old glibc sources,
and old gcc sources won't build with new glibc sources, which is
likely to cause trouble. Maybe we can add a glibc version test and
use the appropriate field names and types to fix this. Alittle
inconvenient but workable.

However, gcc is probably not the only program or library that uses the
sigcontext type. You would have to find and fix all of them. You
could trying doing an openembedded build with the glibc change, and
then try to build all packages that are ported to riscv to see how
many break. Just to get an indication of how big the problem is.
This won't identify end user codes that aren't part of linux though.
Each company that has a program they build for linux that uses
sigcontext would have to be fixed.

Jim

[Vincent Chen]

I followed your suggestion to do an openembedded build with this Glibc
change, and fortunately, all programs were passed. Therefore, maybe I
can think that the impact of this Glibc change on the riscv ecosystem
is not serious at this moment. In the next step, I will discuss this
issue with Kito to find a better solution for the GCC stack unwinding.

Thank you very much for your comments

Best regards
Vincent