| History log of /src/tests/lib/libc/setjmp/t_sigstack.c |
| Revision | | Date | Author | Comments |
| 1.25 |
| 12-May-2025 |
christos | fix the clang build.
|
| 1.24 |
| 28-Apr-2025 |
martin | PR 59370: compat 1.3 setjmp has been fixed
|
| 1.23 |
| 28-Apr-2025 |
riastradh | tests/lib/libc/setjmp: Mark compat 1.3 setjmp busted on sparc64.
PR port-sparc64/59370: compat 1.3 setjmp is busted
|
| 1.22 |
| 28-Apr-2025 |
riastradh | t_sigstack: Don't do atf_tc_expect_fail then atf_tc_expect_signal.
atf interprets this sequence, with no intervening atf_tc_fail, to
mean the xfail failed to fail so it fails. (Got that?) That is, it
is interpreted somewhat like
atf_tc_expect_fail(...);
... there is supposed to be a failure here ...
atf_tc_expect_pass();
... remaining checks are expected to pass ...
where a lack of failures between the xfail and the xpass means the
expectation was not met.
But in this case, there are two compounding bugs:
1. the compat 1.3 setjmp has botched its registers, as uwe@
discovered, so it is expected to crash on SIGSEGV (PR 59351); and
2. the compat 1.3 longjmp restores the stack poiter and signal mask
in the wrong order, so it is expected to fail the test (PR 57946).
Since the crash in setjmp triggers before the failure after longjmp,
only do atf_tc_expect_signal; once that is fixed we can re-enable the
atf_tc_expect_fail for longjmp.
PR lib/57946: longjmp fails to restore stack first before restoring
signal mask on most architectures
PR port-arm/59351: compat_setjmp is busted
|
| 1.21 |
| 25-Apr-2025 |
riastradh | t_setjmp, t_sigstack: Mark compat13 setjmp tests xfail on arm.
(Does it even make sense to have compat_setjmp on arm? Didn't we
break ABI compatibility with the oabi->eabi transition, long after
1.3?)
PR port-arm/59351: compat_setjmp is busted
|
| 1.20 |
| 24-Apr-2025 |
riastradh | tests/lib/libc/setjmp/t_sigstack: Update xfails.
Designations based on actual test run for i386 and code inspection
for arm and sh3 (and code inspection for all the other architectures
not listed because I expect the tests to pass on them -- they mostly
use sigreturn which will DTRT).
Move the ia64 xfail to just setjmp/sigsetjmp -- no compat13 on ia64.
Nix the long comment now that just about everything has been fixed.
PR lib/57946: longjmp fails to restore stack first before restoring
signal mask on most architectures
|
| 1.19 |
| 24-Apr-2025 |
riastradh | sparc, sparc64 longjmp: Use _UC_SIGMASK to restore signal mask.
This way, restoring the signal mask and restoring the stack pointer
happen atomically with respect to signal handler calls, whereas using
sigprocmask would restore the signal mask _before_ the stack pointer,
breaking sigaltstack.
The motivation for using sigprocmask first and then setcontext later,
rather than _UC_SIGMASK in setcontext, was to get SA-based libpthead
sigprocmask interposition. But that's long gone and unlikely to come
back.
PR lib/57946: longjmp fails to restore stack first before restoring
signal mask on most architectures
|
| 1.18 |
| 24-Apr-2025 |
riastradh | mips longjmp: Use _UC_SIGMASK to restore signal mask.
This way, restoring the signal mask and restoring the stack pointer
happen atomically with respect to signal handler calls, whereas using
sigprocmask would restore the signal mask _before_ the stack pointer,
breaking sigaltstack.
The motivation for using sigprocmask first and then setcontext later,
rather than _UC_SIGMASK in setcontext, was to get SA-based libpthead
sigprocmask interposition. But that's long gone and unlikely to come
back.
PR lib/57946: longjmp fails to restore stack first before restoring
signal mask on most architectures
|
| 1.17 |
| 24-Apr-2025 |
riastradh | mips/compat_longjmp: Make sure compat13 setjmp returns nonzero.
PR port-mips/59285: _longjmp(..., 0) makes setjmp return 0, not 1
|
| 1.16 |
| 24-Apr-2025 |
riastradh | mips/compat_sigsetjmp: Add missing RESTORE_GP64.
Otherwise, compat13 sigsetjmp clobbers the caller's gp when it
returns (the first time around, anyway), which leads to a lovely
display of fireworks.
PR port-mips/59343: compat_sigsetjmp.S: missing RESTORE_GP64
|
| 1.15 |
| 24-Apr-2025 |
riastradh | mips/compat_setjmp: .set reorder doesn't have delay slots.
PR port-mips/59342: compat_setjmp.S is confused about delay slots
|
| 1.14 |
| 24-Apr-2025 |
riastradh | t_setjmp, t_sigstack: Test compat13 setjmp/sigsetjmp too.
PR port-mips/59342: compat_setjmp.S is confused about delay slots
PR port-mips/59343: compat_sigsetjmp.S: missing RESTORE_GP64
|
| 1.13 |
| 13-Apr-2025 |
riastradh | hppa longjmp: Use _UC_SIGMASK to restore signal mask.
This way, restoring the signal mask and restoring the stack pointer
happen atomically with respect to signal handler calls, whereas using
sigprocmask would restore the signal mask _before_ the stack pointer,
breaking sigaltstack.
The motivation for using sigprocmask first and then setcontext later,
rather than _UC_SIGMASK in setcontext, was to get SA-based libpthead
sigprocmask interposition. But that's long gone and unlikely to come
back.
Tested under qemu with:
atf-run /usr/tests/lib/libc/setjmp | atf-report
atf-run /usr/tests/lib/libpthread/t_siglongjmp | atf-report
PR lib/57946: longjmp fails to restore stack first before restoring
signal mask on most architectures
|
| 1.12 |
| 17-Jul-2024 |
uwe | branches: 1.12.2; 1.12.4;
sh3: siglongjmp - restore register context first (PR lib/57946)
|
| 1.11 |
| 06-May-2024 |
riastradh | tests/lib/libc/setjmp/t_sigstack: Add missing comment for 1.10.
PR lib/57946
|
| 1.10 |
| 06-May-2024 |
skrll | arm has been fixed
|
| 1.9 |
| 04-Apr-2024 |
riastradh | i386 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
|
| 1.8 |
| 04-Apr-2024 |
riastradh | amd64 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
|
| 1.7 |
| 19-Feb-2024 |
riastradh | longjmp(3) t_sigstack: Fix fencepost error.
Extremely unlikely to cause trouble, but let's just turn that into
`never' to keep it easier for readers.
PR lib/57946
|
| 1.6 |
| 19-Feb-2024 |
riastradh | longjmp(3) t_sigstack: Use a sigaltstack per handler entry.
longjmp evidently doesn't reset the state of whether the process is
executing on the alternate signal stack. So when we re-enter the
signal handler, the alternate stack appears to be still in use, and
the system chooses the original stack for the second call to the
signal handler -- which trips our assertion asking to verify that the
signal handler is always using an alternate stack.
Not strictly necessary for the signal handler to use an alternate
stack on re-entry, but this makes it clearer that the signal handler
itself is always using the alternate stack so we can verify that the
interrupted code is _not_ in the signal handler.
With this change, the test now passes on aarch64.
PR lib/57946
|
| 1.5 |
| 19-Feb-2024 |
riastradh | longjmp(3) t_sigstack: Note aarch64 seems to DTRT.
But only by code inspection; it appears to have another problem: on
re-entry, the signal handler is called on the normal stack, not on
the alternate signal stack.
PR lib/57946
|
| 1.4 |
| 19-Feb-2024 |
riastradh | longjmp(3) t_sigstack: Print which entry failed.
PR lib/57946
|
| 1.3 |
| 19-Feb-2024 |
riastradh | longjmp(3): Test signal mask vs stack restore with siglongjmp too.
PR lib/57946
|
| 1.2 |
| 19-Feb-2024 |
riastradh | longjmp(3): Paranoia: more error checking in PR lib/57946 test.
|
| 1.1 |
| 19-Feb-2024 |
riastradh | longjmp(3): Add test for PR lib/57946.
|
| 1.12.4.2 |
| 23-Aug-2024 |
martin | Pull up following revision(s) (requested by riastradh in ticket #795):
tests/lib/libc/setjmp/Makefile: revision 1.3
distrib/sets/lists/debug/mi: revision 1.425
lib/libc/arch/sh3/gen/setjmp.S: revision 1.12
lib/libc/arch/i386/gen/sigsetjmp.S: revision 1.19
lib/libc/arch/x86_64/gen/__setjmp14.S: revision 1.4
tests/lib/libc/setjmp/t_sigstack.c: revision 1.10
tests/lib/libc/setjmp/t_sigstack.c: revision 1.11
tests/lib/libc/setjmp/t_sigstack.c: revision 1.12
tests/lib/libc/setjmp/t_sigstack.c: revision 1.1
lib/libc/arch/sh3/gen/sigsetjmp.S: revision 1.11
tests/lib/libc/setjmp/t_sigstack.c: revision 1.2
tests/lib/libc/setjmp/t_sigstack.c: revision 1.3
tests/lib/libc/setjmp/t_sigstack.c: revision 1.4
tests/lib/libc/setjmp/t_sigstack.c: revision 1.5
tests/lib/libc/setjmp/t_sigstack.c: revision 1.6
lib/libc/arch/arm/gen/setjmp.S: revision 1.19
tests/lib/libc/setjmp/t_sigstack.c: revision 1.7
tests/lib/libc/setjmp/t_sigstack.c: revision 1.8
tests/lib/libc/setjmp/t_sigstack.c: revision 1.9
lib/libc/arch/i386/gen/setjmp.S: revision 1.18
lib/libc/arch/x86_64/gen/__sigsetjmp14.S: revision 1.4
distrib/sets/lists/tests/mi: revision 1.1306 (patch)
longjmp(3): Add test for PR lib/57946.
longjmp(3): Paranoia: more error checking in PR lib/57946 test.
longjmp(3): Test signal mask vs stack restore with siglongjmp too.
PR lib/57946
longjmp(3) t_sigstack: Print which entry failed.
PR lib/57946
longjmp(3) t_sigstack: Note aarch64 seems to DTRT.
But only by code inspection; it appears to have another problem: on
re-entry, the signal handler is called on the normal stack, not on
the alternate signal stack.
PR lib/57946
longjmp(3) t_sigstack: Use a sigaltstack per handler entry.
longjmp evidently doesn't reset the state of whether the process is
executing on the alternate signal stack. So when we re-enter the
signal handler, the alternate stack appears to be still in use, and
the system chooses the original stack for the second call to the
signal handler -- which trips our assertion asking to verify that the
signal handler is always using an alternate stack.
Not strictly necessary for the signal handler to use an alternate
stack on re-entry, but this makes it clearer that the signal handler
itself is always using the alternate stack so we can verify that the
interrupted code is _not_ in the signal handler.
With this change, the test now passes on aarch64.
PR lib/57946
longjmp(3) t_sigstack: Fix fencepost error.
Extremely unlikely to cause trouble, but let's just turn that into
`never' to keep it easier for readers.
PR lib/57946
amd64 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
i386 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
arm longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Move the botched sp and lr tests earlier.
PR lib/57946
arm has been fixed
tests/lib/libc/setjmp/t_sigstack: Add missing comment for 1.10.
PR lib/57946
sh3: siglongjmp - restore register context first (PR lib/57946)
|
| 1.12.4.1 |
| 17-Jul-2024 |
martin | file t_sigstack.c was added on branch netbsd-9 on 2024-08-23 16:59:51 +0000
|
| 1.12.2.2 |
| 23-Aug-2024 |
martin | Pull up following revision(s) (requested by riastradh in ticket #795):
tests/lib/libc/setjmp/Makefile: revision 1.3
distrib/sets/lists/debug/mi: revision 1.425
lib/libc/arch/sh3/gen/setjmp.S: revision 1.12
lib/libc/arch/i386/gen/sigsetjmp.S: revision 1.19
lib/libc/arch/x86_64/gen/__setjmp14.S: revision 1.4
tests/lib/libc/setjmp/t_sigstack.c: revision 1.10
tests/lib/libc/setjmp/t_sigstack.c: revision 1.11
tests/lib/libc/setjmp/t_sigstack.c: revision 1.12
tests/lib/libc/setjmp/t_sigstack.c: revision 1.1
lib/libc/arch/sh3/gen/sigsetjmp.S: revision 1.11
tests/lib/libc/setjmp/t_sigstack.c: revision 1.2
tests/lib/libc/setjmp/t_sigstack.c: revision 1.3
tests/lib/libc/setjmp/t_sigstack.c: revision 1.4
tests/lib/libc/setjmp/t_sigstack.c: revision 1.5
tests/lib/libc/setjmp/t_sigstack.c: revision 1.6
lib/libc/arch/arm/gen/setjmp.S: revision 1.19
tests/lib/libc/setjmp/t_sigstack.c: revision 1.7
tests/lib/libc/setjmp/t_sigstack.c: revision 1.8
tests/lib/libc/setjmp/t_sigstack.c: revision 1.9
lib/libc/arch/i386/gen/setjmp.S: revision 1.18
lib/libc/arch/x86_64/gen/__sigsetjmp14.S: revision 1.4
distrib/sets/lists/tests/mi: revision 1.1306
longjmp(3): Add test for PR lib/57946.
longjmp(3): Paranoia: more error checking in PR lib/57946 test.
longjmp(3): Test signal mask vs stack restore with siglongjmp too.
PR lib/57946
longjmp(3) t_sigstack: Print which entry failed.
PR lib/57946
longjmp(3) t_sigstack: Note aarch64 seems to DTRT.
But only by code inspection; it appears to have another problem: on
re-entry, the signal handler is called on the normal stack, not on
the alternate signal stack.
PR lib/57946
longjmp(3) t_sigstack: Use a sigaltstack per handler entry.
longjmp evidently doesn't reset the state of whether the process is
executing on the alternate signal stack. So when we re-enter the
signal handler, the alternate stack appears to be still in use, and
the system chooses the original stack for the second call to the
signal handler -- which trips our assertion asking to verify that the
signal handler is always using an alternate stack.
Not strictly necessary for the signal handler to use an alternate
stack on re-entry, but this makes it clearer that the signal handler
itself is always using the alternate stack so we can verify that the
interrupted code is _not_ in the signal handler.
With this change, the test now passes on aarch64.
PR lib/57946
longjmp(3) t_sigstack: Fix fencepost error.
Extremely unlikely to cause trouble, but let's just turn that into
`never' to keep it easier for readers.
PR lib/57946
amd64 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
i386 longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
arm longjmp: Restore stack first, then signal mask.
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Move the botched sp and lr tests earlier.
PR lib/57946
arm has been fixed
tests/lib/libc/setjmp/t_sigstack: Add missing comment for 1.10.
PR lib/57946
sh3: siglongjmp - restore register context first (PR lib/57946)
|
| 1.12.2.1 |
| 17-Jul-2024 |
martin | file t_sigstack.c was added on branch netbsd-10 on 2024-08-23 16:56:29 +0000
|
