Re: CVS commit: src/tests/lib/libc/sys
Date:Mon, 1 Aug 2022 18:55:15 +0300 From:Valery Ushakov Message-ID: | The test uses __clone(), not clone() and a followup fix made __clone() | visible under plain _NETBSD_SOURCE again - which is the right thing, | IMO. So this change is not necessary (the test only uses __clone()). Yes, I saw, but the test really should be using clone() - that"s the thing which needs to work (for those odd apps which use it). kre
Re: CVS commit: src/tests/lib/libc/sys
On Mon, Aug 01, 2022 at 15:48:40 +, Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Mon Aug 1 15:48:40 UTC 2022 > > Modified Files: > src/tests/lib/libc/sys: Makefile > > Log Message: > Provide _GNU_SOURCE for t_clone now that is required to make clone() > visible. The test uses __clone(), not clone() and a followup fix made __clone() visible under plain _NETBSD_SOURCE again - which is the right thing, IMO. So this change is not necessary (the test only uses __clone()). -uwe
Re: CVS commit: src/tests/lib/libc/sys
Committed. Thank you for your comment! rin On 2020/06/22 20:09, Kamil Rytarowski wrote: On 22.06.2020 04:51, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Mon Jun 22 02:51:07 UTC 2020 Modified Files: src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_wait.h Log Message: Turn trigger_fpe() back to integer division by zero for a while until QEMU bug #1668041 is fixed: https://bugs.launchpad.net/qemu/+bug/1668041 by which floating-point division by zero is not trapped correctly both on amd64 and i386. Skip *_crash_fpe tests on powerpc, where integer division by zero is never trapped. The intention of this test is just detecting SIGFPE. If the si_code value is various on different architectures (like one traps on integers other one on floats), we shall just drop the asserts for si_code and adapt the trigger_fpe() function to cover promptly more ports. The qemu bug should be fixed nonetheless.
Re: CVS commit: src/tests/lib/libc/sys
On 22.06.2020 04:51, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Mon Jun 22 02:51:07 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_wait.h > > Log Message: > Turn trigger_fpe() back to integer division by zero for a while > until QEMU bug #1668041 is fixed: > > https://bugs.launchpad.net/qemu/+bug/1668041 > > by which floating-point division by zero is not trapped correctly > both on amd64 and i386. > > Skip *_crash_fpe tests on powerpc, where integer division by zero > is never trapped. > The intention of this test is just detecting SIGFPE. If the si_code value is various on different architectures (like one traps on integers other one on floats), we shall just drop the asserts for si_code and adapt the trigger_fpe() function to cover promptly more ports. The qemu bug should be fixed nonetheless. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
On 2020/06/17 17:42, Rin Okuyama wrote: Now, all *_crash_fpe tests pass for powerpc, and nothing changes for amd64 at least. Here, powerpc means powerpc/oea, more specifically Mac mini G4. At the moment, fenv.h doesn't work correctly on booke and ibm4xx, where FPU is emulated in software. For some processors of oea, m[ft]msr instructions used in fenv.h may be privileged, and need similar care as booke/ibm4xx. Thanks, rin
Re: CVS commit: src/tests/lib/libc/sys
On Sat, Jun 06, 2020 at 06:11:21PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Sat Jun 6 18:11:21 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_lwp_create.c > > Log Message: > Add a test case to ensure that _lwp_create() fails with the > expected error code when a bad new-lwp-id pointer is passed. Was thinking of just this yesterday - thanks! It's a fragile bit of code and has been fixed 3x already this year. Andrew
Re: CVS commit: src/tests/lib/libc/sys
On 15.05.2020 00:43, Taylor R Campbell wrote: >> Date: Thu, 14 May 2020 23:36:28 +0200 >> From: Kamil Rytarowski >> >> If a signal would not reach the child process (as it is ignored or >> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I >> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX. >> Race free signals could be maybe possible, but with some design rethinking. > > I don't understand -- are you saying that if I mask SIGCHLD, e.g. with > sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE > set, any SIGCHLD signals will be discarded while I have it masked? > That's it. But it will be discarded only when there is no SIGCHLD signal handler installed. That's the case in the test. A debugger catches regular signals only (except crash related ones) when they reach the debuggee, > This can't be right, so either I misunderstood what you're saying, or > something else is afoot with the test that is making it flaky, or > there's a bug in the kernel. > It's a design. If we install a signal handler for SIGCHLD in the traced the test is very stable and we note SIGCHLD always, so there is no bug. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
> Date: Thu, 14 May 2020 23:36:28 +0200 > From: Kamil Rytarowski > > If a signal would not reach the child process (as it is ignored or > masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I > checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX. > Race free signals could be maybe possible, but with some design rethinking. I don't understand -- are you saying that if I mask SIGCHLD, e.g. with sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE set, any SIGCHLD signals will be discarded while I have it masked? This can't be right, so either I misunderstood what you're saying, or something else is afoot with the test that is making it flaky, or there's a bug in the kernel.
Re: CVS commit: src/tests/lib/libc/sys
On Thu, May 14, 2020 at 11:36:28PM +0200, Kamil Rytarowski wrote: > On 14.05.2020 23:02, Joerg Sonnenberger wrote: > > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote: > >> Module Name: src > >> Committed By: kamil > >> Date: Thu May 14 19:21:35 UTC 2020 > >> > >> Modified Files: > >>src/tests/lib/libc/sys: t_ptrace_fork_wait.h > >> > >> Log Message: > >> Ignore interception of the SIGCHLD signals. > >> > >> SIGCHLD once blocked is discarded by the kernel as it has the > >> SA_IGNORE property. During the fork(2) operation all signals can be > >> shortly blocked and missed (unless there is a registered signal > >> handler in the traced child). This leads to a race in this test if > >> there would be an intention to catch SIGCHLD. > > > > This doesn't sound right. sigprocmask and pthread_sigmask shouldn't > > affect whether the signal handler is called, only when. Temporarily > > masking a signal is different from setting it to SIG_IGN. > > > > Joerg > > > > I was looking into it and as there is no signal handler for SIGCHLD, the > signal is discarded. Sure, but that doesn't really have anything to do with signal blocking. That's the part that is confusing. Joerg
Re: CVS commit: src/tests/lib/libc/sys
On 14.05.2020 23:02, Joerg Sonnenberger wrote: > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Thu May 14 19:21:35 UTC 2020 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ptrace_fork_wait.h >> >> Log Message: >> Ignore interception of the SIGCHLD signals. >> >> SIGCHLD once blocked is discarded by the kernel as it has the >> SA_IGNORE property. During the fork(2) operation all signals can be >> shortly blocked and missed (unless there is a registered signal >> handler in the traced child). This leads to a race in this test if >> there would be an intention to catch SIGCHLD. > > This doesn't sound right. sigprocmask and pthread_sigmask shouldn't > affect whether the signal handler is called, only when. Temporarily > masking a signal is different from setting it to SIG_IGN. > > Joerg > I was looking into it and as there is no signal handler for SIGCHLD, the signal is discarded. Another approach to fix the race would be to: 1. Add SIGCHLD signal handler in the traced child. 2. Explicitly masking SIGCHLD in the traced child. If a signal would not reach the child process (as it is ignored or masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX. Race free signals could be maybe possible, but with some design rethinking. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Thu May 14 19:21:35 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_fork_wait.h > > Log Message: > Ignore interception of the SIGCHLD signals. > > SIGCHLD once blocked is discarded by the kernel as it has the > SA_IGNORE property. During the fork(2) operation all signals can be > shortly blocked and missed (unless there is a registered signal > handler in the traced child). This leads to a race in this test if > there would be an intention to catch SIGCHLD. This doesn't sound right. sigprocmask and pthread_sigmask shouldn't affect whether the signal handler is called, only when. Temporarily masking a signal is different from setting it to SIG_IGN. Joerg
Re: CVS commit: src/tests/lib/libc/sys
Date:Mon, 11 May 2020 13:47:45 +0200 From:Kamil Rytarowski Message-ID: <54178983-82d1-df3d-fd54-549a6c73f...@gmx.com> | The only purpose of the test is to check whether misaligned program | counter can crash the kernel (it can for NetBSD/sparc). Later, if a | process dies or runs is not important, thus it is being killed. That's all fine. | A process can disappear after dying and before reappearing as a zombie. There's a state between running and dead (zombie), that's correct - but it really doesn't matter, once the process ceases to be alive, it is beyond killing any more. | This is not a bug, but a predicted race. Yes, that's what I said, and that's fine too. | Doing the kill once (and missing the process) is still possibly enough, | but correcting it with SIGKILL does not cost. No, there is no problem with doing the SIGKILL, but if fails for the above reason, there's absolutely no point trying again. The process is gone, it isn't coming back. It doesn't need killing. But even if there was a reason to try again (there isn't), one more attempt would do - inserting an infinite loop is folly. But I see that you have fixed it, that's good, what's there now looks much better. Thanks. kre
Re: CVS commit: src/tests/lib/libc/sys
On 11.05.2020 13:35, Robert Elz wrote: > Date:Mon, 11 May 2020 11:03:15 + > From:"Kamil Rytarowski" > Message-ID: <2020050315.54b13f...@cvs.netbsd.org> > > | Do not fail when trying to kill a dying process > | > | A dying process can disappear for a while. Rather than aborting, retry > | sending SIGKILL to it. > > I don't understand this ... a process should never be able to > disappear and then reappear (not in any way). If a SIGKILL (or > ptrace(PT_KILL) fails with a "no such process" error, then repeating > it won't (or shouldn't) help - if it does, there's a kernel bug that > needs fixing (and it is OK for the test to fail until that happens.) > > Further, if the reason for this failure is that the process is > dying, you probably never needed the kill in the first place (and > no, I don't mean it should be deleted - the parent is unlikely to > know the state of the child, so killing it, if that is what is needed > is the right thing to do ... just that if the kill fails because you > were too late issuing it, it isn't an error, just a race that you lost, > and certainly shouldn't be repeated). > > But more than that, adding an infinite loop to the test, where you keep > doing the kill forever until it succeeds, or errno somehow stops being > ESRCH looks like a recipe for disaster. > > Just do the kill once, ignore the error if it is ESRCH (and probably > also ECHILD) report other errors as failures. > > kre > The only purpose of the test is to check whether misaligned program counter can crash the kernel (it can for NetBSD/sparc). Later, if a process dies or runs is not important, thus it is being killed. A process can disappear after dying and before reappearing as a zombie. This is not a bug, but a predicted race. We already discussed it in the past, whether to return the same process multiple times or overlook it for a while during the transition dying->zombie. Once an entity died it disappeared so the same is true for a process. Doing the kill once (and missing the process) is still possibly enough, but correcting it with SIGKILL does not cost. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
Date:Mon, 11 May 2020 11:03:15 + From:"Kamil Rytarowski" Message-ID: <2020050315.54b13f...@cvs.netbsd.org> | Do not fail when trying to kill a dying process | | A dying process can disappear for a while. Rather than aborting, retry | sending SIGKILL to it. I don't understand this ... a process should never be able to disappear and then reappear (not in any way). If a SIGKILL (or ptrace(PT_KILL) fails with a "no such process" error, then repeating it won't (or shouldn't) help - if it does, there's a kernel bug that needs fixing (and it is OK for the test to fail until that happens.) Further, if the reason for this failure is that the process is dying, you probably never needed the kill in the first place (and no, I don't mean it should be deleted - the parent is unlikely to know the state of the child, so killing it, if that is what is needed is the right thing to do ... just that if the kill fails because you were too late issuing it, it isn't an error, just a race that you lost, and certainly shouldn't be repeated). But more than that, adding an infinite loop to the test, where you keep doing the kill forever until it succeeds, or errno somehow stops being ESRCH looks like a recipe for disaster. Just do the kill once, ignore the error if it is ESRCH (and probably also ECHILD) report other errors as failures. kre
Re: CVS commit: src/tests/lib/libc/sys
On 24.04.2020 05:25, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Fri Apr 24 03:25:20 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_x86_wait.h > > Log Message: > Update for new LWP behavior -- as of 9.99.59, the LWP ID of a single-LWP > process is the PID, not 1. > Thanks. These tests shall not rely on specific LWP numbers and I will remove the asserts. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
In article <5e528f7a-147a-23e7-46da-6b02d76e5...@gmx.com>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 07.03.2020 15:53, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sat Mar 7 14:53:14 UTC 2020 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h >> >> Log Message: >> Try to fix the build. This is why all those inlines should really be in a >> separate file as regular function. The code is too large and hard to manage >> this way, and only increases in complexity as time goes by. >> >> > >What build configuration was broken? All of the evbarm ones since t_ptrace_sigchld.c was not including ieefp.h http://releng.netbsd.org/builds/HEAD/202003070040Z/evbarm-earmhfeb.build.failed christos
Re: CVS commit: src/tests/lib/libc/sys
On 07.03.2020 15:53, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Mar 7 14:53:14 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h > > Log Message: > Try to fix the build. This is why all those inlines should really be in a > separate file as regular function. The code is too large and hard to manage > this way, and only increases in complexity as time goes by. > > What build configuration was broken? signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
On 18.02.2020 16:57, Christos Zoulas wrote: > In article <20200213152742.081a9f...@cvs.netbsd.org>, > MichaŠGórny wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:mgorny >> Date:Thu Feb 13 15:27:41 UTC 2020 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ptrace_wait.c >> >> Log Message: >> Enable combined breakpoint, watchpoint and signal tests > > Let's split this file up. The name does not reflect anymore what this > is testing and it has become more than 9000 lines long. Because of the > complexity it keeps breaking the build and because of the size it makes > fixing it awkward. Kamil/Michal, can you please work on this? > [ for example the llvm builds are currently broken ] > > Thanks, > > christos > I will do it. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
In article <20200213152742.081a9f...@cvs.netbsd.org>, MichaŠGórny wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: mgorny >Date: Thu Feb 13 15:27:41 UTC 2020 > >Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.c > >Log Message: >Enable combined breakpoint, watchpoint and signal tests Let's split this file up. The name does not reflect anymore what this is testing and it has become more than 9000 lines long. Because of the complexity it keeps breaking the build and because of the size it makes fixing it awkward. Kamil/Michal, can you please work on this? [ for example the llvm builds are currently broken ] Thanks, christos
Re: CVS commit: src/tests/lib/libc/sys
In article <20200213114904.ga30...@bec.de>, Joerg Sonnenberger wrote: >On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote: >> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote: >> > Module Name: src >> > Committed By: christos >> > Date: Thu Feb 13 02:53:46 UTC 2020 >> > >> > Modified Files: >> >src/tests/lib/libc/sys: t_ptrace_x86_wait.h >> > >> > Log Message: >> > Turn off optimization on a function which contains constant labels. >> > The optimizer splits it and we end up with 2 copies and duplicate symbols. >> >> Why not just turn them into local labels instead? > >Alternatively, suffixing them with %= would create unique labels. I was looking for that :-) christos
Re: CVS commit: src/tests/lib/libc/sys
In article <20200213095019.ga28...@bec.de>, Joerg Sonnenberger wrote: >On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Thu Feb 13 02:53:46 UTC 2020 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ptrace_x86_wait.h >> >> Log Message: >> Turn off optimization on a function which contains constant labels. >> The optimizer splits it and we end up with 2 copies and duplicate symbols. > >Why not just turn them into local labels instead? You mean 1f etc? I was not sure if that would work in the symbol defined case. christos
Re: CVS commit: src/tests/lib/libc/sys
On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote: > On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote: > > Module Name:src > > Committed By: christos > > Date: Thu Feb 13 02:53:46 UTC 2020 > > > > Modified Files: > > src/tests/lib/libc/sys: t_ptrace_x86_wait.h > > > > Log Message: > > Turn off optimization on a function which contains constant labels. > > The optimizer splits it and we end up with 2 copies and duplicate symbols. > > Why not just turn them into local labels instead? Alternatively, suffixing them with %= would create unique labels. Joerg
Re: CVS commit: src/tests/lib/libc/sys
On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Feb 13 02:53:46 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_x86_wait.h > > Log Message: > Turn off optimization on a function which contains constant labels. > The optimizer splits it and we end up with 2 copies and duplicate symbols. Why not just turn them into local labels instead? Joerg
Re: CVS commit: src/tests/lib/libc/sys
On 01.07.2019 14:59, Robert Elz wrote: > Date:Mon, 1 Jul 2019 11:55:57 +0200 > From:Joerg Sonnenberger > Message-ID: <20190701095557.ga55...@bec.de> > > | On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote: > > | > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential > | > signedness bit shifts. > | > | This change makes no sense. > > Certainly the size_t cast is pointless ... and I have no idea what > the comment in the commit message about bit shifts is about, this is > (was) a simple comparison of an unsigned with a signed, which the > cast to ssize_t turns into a signed comparison, which is as it should be. > There are no bit shifts. > > kre > > OK, it was cast of 32bit value to ssize_t that can be 64bit. The original type is uint32_t, not int32_t, so intermediate cast is not needed. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
Date:Mon, 1 Jul 2019 11:55:57 +0200 From:Joerg Sonnenberger Message-ID: <20190701095557.ga55...@bec.de> | On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote: | > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential | > signedness bit shifts. | | This change makes no sense. Certainly the size_t cast is pointless ... and I have no idea what the comment in the commit message about bit shifts is about, this is (was) a simple comparison of an unsigned with a signed, which the cast to ssize_t turns into a signed comparison, which is as it should be. There are no bit shifts. kre
Re: CVS commit: src/tests/lib/libc/sys
On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Mon Jul 1 02:04:38 UTC 2019 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.c > > Log Message: > Avoid GCC warning on NetBSD/i386 > > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential > signedness bit shifts. This change makes no sense. Joerg
Re: CVS commit: src/tests/lib/libc/sys
> On May 24, 2018, at 10:45 PM, Kamil Rytarowski wrote: > > Fixed! Confirmed! Thanks! -- thorpej
Re: CVS commit: src/tests/lib/libc/sys
On 24.05.2018 06:17, Jason Thorpe wrote: > This change seems to have broken building on 32-bit platforms (certainly at > least for 32-bit ARM): > > # compile sys/t_ptrace_wait.o > /nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2 -std=gnu99-Wall > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare > -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type > -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter > -Wno-sign-compare -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror > -Wno-missing-noreturn -fPIE--sysroot=/nbsd/destdir/rpi > -I/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/../../.. -c > -D_KERNTYPES > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c > In file included from > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c:59:0: > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h: In > function 'trigger_bus': > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:20: > error: cast from pointer to integer of different size > [-Werror=pointer-to-int-cast] > FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL); > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: > note: in definition of macro 'FORKEE_ASSERT_NEQ' > uintmax_t vx = (x); \ > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:35: > error: cast from pointer to integer of different size > [-Werror=pointer-to-int-cast] > FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL); >^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: > note: in definition of macro 'FORKEE_ASSERT_NEQ' > uintmax_t vy = (y); \ > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:20: > error: cast from pointer to integer of different size > [-Werror=pointer-to-int-cast] > FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED); > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: > note: in definition of macro 'FORKEE_ASSERT_NEQ' > uintmax_t vx = (x); \ > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:34: > error: cast from pointer to integer of different size > [-Werror=pointer-to-int-cast] > FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED); > ^ > /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: > note: in definition of macro 'FORKEE_ASSERT_NEQ' > uintmax_t vy = (y); \ > ^ > cc1: all warnings being treated as errors > > *** Failed target: t_ptrace_wait.o > > > Maybe uintptr_t is a better type to cast to? > > >> On May 23, 2018, at 6:18 AM, Kamil Rytarowski wrote: >> >> Module Name: src >> Committed By:kamil >> Date:Wed May 23 13:18:09 UTC 2018 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ptrace_wait.h >> >> Log Message: >> Add new auxiliary functions in ATF ptrace(2) tests >> >> Introduce: >> - trigger_trap() >> - trigger_segv() >> - trigger_ill() >> - trigger_fpe() >> - trigger_bus() >> >> These functions generate appropriate signals caused by crashes. >> >> A debugger is required to collect the crashes regardless of signal masking, >> catching or ignoring rules. >> >> While there, append __used argument to can_we_set_dbregs(). >> >> Sponsored by >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/sys/t_ptrace_wait.h >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> > > -- thorpej > Fixed! signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
This change seems to have broken building on 32-bit platforms (certainly at least for 32-bit ARM): # compile sys/t_ptrace_wait.o /nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror -Wno-missing-noreturn -fPIE--sysroot=/nbsd/destdir/rpi -I/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/../../.. -c -D_KERNTYPES /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c In file included from /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c:59:0: /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h: In function 'trigger_bus': /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL); ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: note: in definition of macro 'FORKEE_ASSERT_NEQ' uintmax_t vx = (x); \ ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:35: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL); ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: note: in definition of macro 'FORKEE_ASSERT_NEQ' uintmax_t vy = (y); \ ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED); ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: note: in definition of macro 'FORKEE_ASSERT_NEQ' uintmax_t vx = (x); \ ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:34: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED); ^ /Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: note: in definition of macro 'FORKEE_ASSERT_NEQ' uintmax_t vy = (y); \ ^ cc1: all warnings being treated as errors *** Failed target: t_ptrace_wait.o Maybe uintptr_t is a better type to cast to? > On May 23, 2018, at 6:18 AM, Kamil Rytarowski wrote: > > Module Name: src > Committed By: kamil > Date: Wed May 23 13:18:09 UTC 2018 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.h > > Log Message: > Add new auxiliary functions in ATF ptrace(2) tests > > Introduce: > - trigger_trap() > - trigger_segv() > - trigger_ill() > - trigger_fpe() > - trigger_bus() > > These functions generate appropriate signals caused by crashes. > > A debugger is required to collect the crashes regardless of signal masking, > catching or ignoring rules. > > While there, append __used argument to can_we_set_dbregs(). > > Sponsored by > > > To generate a diff of this commit: > cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/sys/t_ptrace_wait.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/tests/lib/libc/sys
On 27.02.2018 12:48, Valery Ushakov wrote: > On Tue, Feb 27, 2018 at 11:15:53 +, Kamil Rytarowski wrote: > >> Module Name: src >> Committed By:kamil >> Date:Tue Feb 27 11:15:53 UTC 2018 >> >> Modified Files: >> src/tests/lib/libc/sys: t_ucontext.c >> >> Log Message: >> Make the t_ucontext.c test more portable >> >> Cast _UC_MACHINE_*(&u) to (register_t). >> This allows to print the returned values with PRIxREGISTER. >> >> This corrects build failures on MIPS and HPPA. >> sizeof(int) == sizeof(long) on these 32-bit systems. > > Why does this code use instead of ? > > Note, that PRIxREGISTER and other kernel PRIx* macros are, for better > or worse, not coming from inttypes headers, but from > . But they can be deined in terms of standard PRIx* > macros and for the userland code those are officially defined by > . > > -uwe > Fixed! signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/tests/lib/libc/sys
On Tue, Feb 27, 2018 at 11:15:53 +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Tue Feb 27 11:15:53 UTC 2018 > > Modified Files: > src/tests/lib/libc/sys: t_ucontext.c > > Log Message: > Make the t_ucontext.c test more portable > > Cast _UC_MACHINE_*(&u) to (register_t). > This allows to print the returned values with PRIxREGISTER. > > This corrects build failures on MIPS and HPPA. > sizeof(int) == sizeof(long) on these 32-bit systems. Why does this code use instead of ? Note, that PRIxREGISTER and other kernel PRIx* macros are, for better or worse, not coming from inttypes headers, but from . But they can be deined in terms of standard PRIx* macros and for the userland code those are officially defined by . -uwe
Re: CVS commit: src/tests/lib/libc/sys
help On Tue, May 23, 2017 at 7:01 PM, Christos Zoulas wrote: > Module Name:src > Committed By: christos > Date: Tue May 23 16:01:46 UTC 2017 > > Modified Files: > src/tests/lib/libc/sys: t_mincore.c > > Log Message: > Add the error in syscall failure. > > > To generate a diff of this commit: > cvs rdiff -u -r1.10 -r1.11 src/tests/lib/libc/sys/t_mincore.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > >
Re: CVS commit: src/tests/lib/libc/sys
Module Name:src Committed By: martin Date: Fri Mar 24 08:18:27 UTC 2017 Modified Files: src/tests/lib/libc/sys: t_mprotect.c Log Message: Do not toggle global security.pax.mprotect state in an attempt to activate it for the current process. It does not work and tests should not change global system state anyway. Instead: skip the test is pax.mprotect is not globally enabled. We could use a better check for this (querying the current processes pax flags), but unfortunately we don't have one. I'll be committing a new sysctl variable proc.curproc.paxflags which will provide the ability to quest the current process's pax flags (or, indeed, the pax flags for any process which the caller is "allowed to see"). +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: CVS commit: src/tests/lib/libc/sys
Should address PR bin/51869 On Sat, 14 Jan 2017, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Sat Jan 14 03:59:58 UTC 2017 Modified Files: src/tests/lib/libc/sys: Makefile Log Message: Set FILESBUILD=yes to actually run the creation script for the file. Should fix the build by creating a file which install can then find. To generate a diff of this commit: cvs rdiff -u -r1.46 -r1.47 src/tests/lib/libc/sys/Makefile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5879a267143851834045299! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: CVS commit: src/tests/lib/libc/sys
Date:Tue, 9 Aug 2016 12:02:44 + From:"Robert Elz" Message-ID: <20160809120244.9f9d0f...@cvs.netbsd.org> Ignore this part ... | Note that NetBSD mlock(2) talks about EINVAL for cases where the length | parameter is negative ... but that is a size_t - good luck having that | ever occur (the man page will soon be corrected as well.) I was reading the man page on a NetBSD-7 system ... didn't notice that the man page was already corrected in current until I went to fix it! kre
Re: CVS commit: src/tests/lib/libc/sys
On Sat, Mar 09, 2013 at 12:19:08AM +0100, Martin Husemann wrote: > On Fri, Mar 08, 2013 at 11:03:23PM +, David Laight wrote: > > Should the 'no timeout' case (try to) check that the elapsed time is > > less than one tick? > > I gave the (partly virtual) test platforms a bit more slope and made it < 1s > instead of 1 tick, but otherwise: yes. If the test did: poll(0, 0, 1); gettimeofday(); run_test(); gettimeofday(); It should be able to distinguish between the 'no sleep' and 'sleep for one tick' cases. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/tests/lib/libc/sys
On Fri, Mar 08, 2013 at 11:03:23PM +, David Laight wrote: > Should the 'no timeout' case (try to) check that the elapsed time is > less than one tick? I gave the (partly virtual) test platforms a bit more slope and made it < 1s instead of 1 tick, but otherwise: yes. Martin
Re: CVS commit: src/tests/lib/libc/sys
On Fri, Mar 08, 2013 at 05:01:54PM +, Martin Husemann wrote: > Module Name: src > Committed By: martin > Date: Fri Mar 8 17:01:54 UTC 2013 > > Modified Files: > src/tests/lib/libc/sys: Makefile > Added Files: > src/tests/lib/libc/sys: t_sigtimedwait.c > Removed Files: > src/tests/lib/libc/sys: t_sigtimedwait_pr_47625.c > > Log Message: > Rename testprogram and make it more general by adding other testcases. > One commented out, I didn't manage to get all signal handling correct > for now. Should the 'no timeout' case (try to) check that the elapsed time is less than one tick? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/tests/lib/libc/sys
On Sep 8, 4:32pm, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: CVS commit: src/tests/lib/libc/sys | On Sat, Sep 08, 2012 at 02:28:53PM +, Christos Zoulas wrote: | > Why not add a test for == VM_MIN_ADDRESS too? | | If this is != NULL, we can not rely on it not to be mapped, so I don't | see any additional value in that case. The brk+1 page test should be good | enough. Thanks for explaining. christos
Re: CVS commit: src/tests/lib/libc/sys
On Sat, Sep 08, 2012 at 02:28:53PM +, Christos Zoulas wrote: > Why not add a test for == VM_MIN_ADDRESS too? If this is != NULL, we can not rely on it not to be mapped, so I don't see any additional value in that case. The brk+1 page test should be good enough. Martin
Re: CVS commit: src/tests/lib/libc/sys
In article <20120908122506.92aa117...@cvs.netbsd.org>, Martin Husemann wrote: >Module Name: src >Committed By: martin >Date: Sat Sep 8 12:25:06 UTC 2012 > >Modified Files: > src/tests/lib/libc/sys: t_mlock.c > >Log Message: >Make this compile on archs where VM_MIN_ADDRESS is not defined (or not >exported to userland) Why not add a test for == VM_MIN_ADDRESS too? christos