| Message ID | 20220613203554.824652-1-mathieu.desnoyers@efficios.com |
|---|---|
| State | New |
| Headers | show |
| Series | linux: add RISC-V rseq signature | expand |
* Mathieu Desnoyers: > From: Michael Jeanson <mjeanson@efficios.com> > > The rseq syscall for the RISC-V architecture was added in Linux 5.18. > > Signed-off-by: Michael Jeanson <mjeanson@efficios.com> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> I think the current guidance is that if you use Signed-off-by:, newly added files shouldn't have FSF copyright. With FSF copyright, the year on new files should start 2022, per FSF guidance. > +#if __BYTE_ORDER == __LITTLE_ENDIAN > +#define RSEQ_SIG 0xf1401073 > +#endif “# define” per our style, I think. (I haven't verified that the number is okay.) Thanks, Florian
----- On Jun 13, 2022, at 4:56 PM, Florian Weimer fweimer@redhat.com wrote: > * Mathieu Desnoyers: > >> From: Michael Jeanson <mjeanson@efficios.com> >> >> The rseq syscall for the RISC-V architecture was added in Linux 5.18. >> >> Signed-off-by: Michael Jeanson <mjeanson@efficios.com> >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > > I think the current guidance is that if you use Signed-off-by:, newly > added files shouldn't have FSF copyright. With FSF copyright, the year > on new files should start 2022, per FSF guidance. Do you mean those files should have no copyright text at all, or should they have a copyright text with the name of the author, or should we use a SPDX license identifier ? Thanks, Mathieu > >> +#if __BYTE_ORDER == __LITTLE_ENDIAN >> +#define RSEQ_SIG 0xf1401073 >> +#endif > > “# define” per our style, I think. (I haven't verified that the number > is okay.) > > Thanks, > Florian
* Mathieu Desnoyers via Libc-alpha: > ----- On Jun 13, 2022, at 4:56 PM, Florian Weimer fweimer@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> From: Michael Jeanson <mjeanson@efficios.com> >>> >>> The rseq syscall for the RISC-V architecture was added in Linux 5.18. >>> >>> Signed-off-by: Michael Jeanson <mjeanson@efficios.com> >>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> >> >> I think the current guidance is that if you use Signed-off-by:, newly >> added files shouldn't have FSF copyright. With FSF copyright, the year >> on new files should start 2022, per FSF guidance. > > Do you mean those files should have no copyright text at all, or > should they have a copyright text with the name of the author, or > should we use a SPDX license identifier ? He current guidance is on the wiki: <https://sourceware.org/glibc/wiki/Contribution%20checklist#Update_copyright_information> It currently suggests Copyright 2022 Free Software Foundation, Inc. for the FSF case (no Signed-off-by: in the commit message), and Copyright The GNU Toolchain Authors. for Developer Certificate of Origin case.
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/rseq.h b/sysdeps/unix/sysv/linux/riscv/bits/rseq.h new file mode 100644 index 0000000000..7cb4e5f284 --- /dev/null +++ b/sysdeps/unix/sysv/linux/riscv/bits/rseq.h @@ -0,0 +1,43 @@ +/* Restartable Sequences Linux RISC-V architecture header. + Copyright (C) 2021-2022 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +#ifndef _SYS_RSEQ_H +# error "Never use <bits/rseq.h> directly; include <sys/rseq.h> instead." +#endif + +#include <bits/endian.h> + +/* + RSEQ_SIG is a signature required before each abort handler code. + + It is a 32-bit value that maps to actual architecture code compiled + into applications and libraries. It needs to be defined for each + architecture. When choosing this value, it needs to be taken into + account that generating invalid instructions may have ill effects on + tools like objdump, and may also have impact on the CPU speculative + execution efficiency in some cases. + + Select the instruction "csrw mhartid, x0" as the RSEQ_SIG. Unlike + other architectures, the ebreak instruction has no immediate field for + distinguishing purposes. Hence, ebreak is not suitable as RSEQ_SIG. + "csrw mhartid, x0" can also satisfy the RSEQ requirement because it + is an uncommon instruction and will raise an illegal instruction + exception when executed in all modes. */ + +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define RSEQ_SIG 0xf1401073 +#endif