Re: elf obj load: skip zero-sized sections early
on 09/07/2010 13:34 Andriy Gapon said the following:
> Having thought and experimented more, I don't see why we need inline assembly
> at
> all and why DPCPU_DEFINE can not simply be defined as follows:
>
> #define DPCPU_DEFINE(t, n)\
> t DPCPU_NAME(n) __section("set_pcpu") \
> __aligned(CACHE_LINE_SIZE) __used
>
More explanation for this proposal with additional technical details,
demonstrations and conclusions.
First, this is the patch that I had in mind (note the file name):
http://people.freebsd.org/~avg/dpcpu/pcpu.bad.patch
Some test code that exercises DPCPU_DEFINE macro in various (redundant) ways:
http://people.freebsd.org/~avg/dpcpu/dpcpu.c
GCC-generated assembly with current version of pcpu.h:
http://people.freebsd.org/~avg/dpcpu/dpcpu.orig.s
Note #APP block, this is what gets produced from the inline assembly.
Also note that GCC-generated section directive has exactly the same parameters
as the parameters we use in the inline assembly - "aw",@progbits.
GCC-generated assembly with patched pcpu.h and its diff from the previous
version:
http://people.freebsd.org/~avg/dpcpu/dpcpu.bad.s
http://people.freebsd.org/~avg/dpcpu/dpcpu.bad.diff
Note the section definition is exactly the same as before - it has the same
flags, its alignment is the same too (.align 128 vs .p2align 7).
It's also obvious where I got confused with this patch (bz, thanks!) and why the
patch is named "bad". Instead of defining alignment for the section the patch
sets CACHE_LINE_SIZE alignment for each variable defined in that section.
Which is a waste, not good, etc.
So, while this patch is bad, it still demonstrated that the real reason for the
inline assembly is defining sections alignment. But the assembly has nothing to
do with "aw" vs "a", variable initialization, etc. Which was my main point.
For completeness, here is a patch that simply drops the inline assembly and the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
As was speculated above, the only thing really changed is section alignment
(from 128 to 4).
And to be continued...
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
>
> As was speculated above, the only thing really changed is section alignment
> (from 128 to 4).
After making the above analysis I wondered why we require set_pcpu section
alignment at all. After all, it's not used as loaded, data from the sections
gets copied into special per-cpu memory areas. So, logically, it's those areas
that need to be aligned, not the section.
svn log and google quickly pointed me to this excellent analysis and explanation
by bz (thanks again!):
http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
Summary: this alignment is needed to work around a bug in GNU binutils ld for
__start_SECNAME placement.
As explained by bz, ld internally generates an equivalent of the following
linker script:
Where NN is an alignment of the first _input_ pcpu_set section found in
whichever .o file happens to be first. Not the resulting alignment of pcpu_set
_output_ section.
Alignment requirement of input sections is based on largest alignment
requirement of section's members. So if section is empty then the required
alignment is 1. Alignment of output section, if not explicitly overridden e.g.
via linker script, is the largest alignment of the corresponding input sections.
I think that the problem can be fixed by making ld define __start_SECNAME like
follows:
...
pcpu_set : {
__start_pcpu_set = ABSOLUTE(.);
...
}
__stop_pcpu_set = .;
This way __start_SECNAME would always point to the actual start of the output
section.
Here's a patch that implements the idea:
http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
This is similar to what was done upstream:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h
The code is quite different there, and approach is somewhat different, but the
idea is the same - place __start_SECNAME inside the section, not outside it.
My testing shows the expected results.
What do you think?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
[oops, sorry, this is not a dup - corrected some omissions/mistakes]
on 11/07/2010 14:54 Andriy Gapon said the following:
> For completeness, here is a patch that simply drops the inline assembly and
> the
> comment about it, and GCC-generated assembly and its diff:
> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
>
> As was speculated above, the only thing really changed is section alignment
> (from 128 to 4).
After making the above analysis I wondered why we require set_pcpu section
alignment at all. After all, it's not used as loaded, data from the section
gets copied into special per-cpu memory areas. So, logically, it's those areas
that need to be aligned, not the section.
svn log and google quickly pointed me to this excellent analysis and explanation
by bz (thanks again!):
http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
Summary: this alignment is needed to work around a bug in GNU binutils ld for
__start_SECNAME placement.
As explained by bz, ld internally generates an equivalent of the following
linker script:
...
__start_pcpu_set = ALIGN(NN);
pcpu_set : {
...
}
__stop_pcpu_set = .;
Where NN is an alignment of the first _input_ pcpu_set section found in
whichever .o file happens to be first. Not the resulting alignment of pcpu_set
_output_ section.
Alignment requirement of input sections is based on largest alignment
requirement of section's members. So if section is empty then the required
alignment is 1. Alignment of output section, if not explicitly overridden e.g.
via linker script, is the largest alignment of the corresponding input sections.
I think that the problem can be fixed by making ld define __start_SECNAME like
follows:
...
pcpu_set : {
__start_pcpu_set = ABSOLUTE(.);
...
}
__stop_pcpu_set = .;
This way __start_SECNAME would always point to the actual start of the output
section.
Here's a patch that implements the idea:
http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
This is similar to what was done upstream:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h
The code is quite different there, and approach is somewhat different, but the
idea is the same - place __start_SECNAME inside the section, not outside it.
My testing shows the expected results.
What do you think?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
strange problem with int64_t variables
Hi, I have two int64_t variables in kernel code, first is stored internally and the second one is passed from a syscall argument. When I print them with printf %lld modifier, the internal one behaves correctly but the other one I pass from a syscall has a corrupted value. If I pass 1, it prints out 3735348794091372545. I'm not doing anything special with it just reading it out from the struct that was generated with make sysent. Any ideas? Thanks, Gabor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange problem with int64_t variables
On 2010-07-11 16:46, Gabor Kovesdan wrote: > I have two int64_t variables in kernel code, first is stored internally > and the second one is passed from a syscall argument. When I print them > with printf %lld modifier, the internal one behaves correctly but the > other one I pass from a syscall has a corrupted value. If I pass 1, it > prints out 3735348794091372545. I'm not doing anything special with it > just reading it out from the struct that was generated with make sysent. Since 3735348794091372545 is 0x33d69ff1, it looks like the upper word got corrupted somehow. Maybe some part of it got non-atomically assigned? Maybe the wrong word was read? It is hard to tell without code... :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange problem with int64_t variables
Em 2010.07.11. 16:54, Dimitry Andric escreveu:
On 2010-07-11 16:46, Gabor Kovesdan wrote:
I have two int64_t variables in kernel code, first is stored internally
and the second one is passed from a syscall argument. When I print them
with printf %lld modifier, the internal one behaves correctly but the
other one I pass from a syscall has a corrupted value. If I pass 1, it
prints out 3735348794091372545. I'm not doing anything special with it
just reading it out from the struct that was generated with make sysent.
Since 3735348794091372545 is 0x33d69ff1, it looks like the upper
word got corrupted somehow. Maybe some part of it got non-atomically
assigned? Maybe the wrong word was read? It is hard to tell without
code... :)
Userland syscall calling:
killjob(getjid(), SIGINT); //getjid() returns 1 this case, whose type
is jid_t
Kernel code:
int
killjob(struct thread *td, struct killjob_args *uap)
{
struct jobentry *jp, *jtmp;
struct procentry *pp, *ptmp;
JOBLIST_WLOCK;
LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) {
if (jp->jid == uap->jid) {
/* never reached code, comparison always fail because
of corrupted value */
}
}
JOBLIST_WUNLOCK;
/* not such job */
td->td_retval[0] = -1;
return (ENOJOB);
}
Gabor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange problem with int64_t variables
On 11.07.2010 18:46, Gabor Kovesdan wrote: > I have two int64_t variables in kernel code, first is stored internally > and the second one is passed from a syscall argument. When I print them > with printf %lld modifier, the internal one behaves correctly but the > other one I pass from a syscall has a corrupted value. If I pass 1, it > prints out 3735348794091372545. I'm not doing anything special with it > just reading it out from the struct that was generated with make sysent. > Any ideas? Can you show some code? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: strange problem with int64_t variables
On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan wrote:
> Em 2010.07.11. 16:54, Dimitry Andric escreveu:
>>
>> On 2010-07-11 16:46, Gabor Kovesdan wrote:
>>
>>>
>>> I have two int64_t variables in kernel code, first is stored internally
>>> and the second one is passed from a syscall argument. When I print them
>>> with printf %lld modifier, the internal one behaves correctly but the
>>> other one I pass from a syscall has a corrupted value. If I pass 1, it
>>> prints out 3735348794091372545. I'm not doing anything special with it
>>> just reading it out from the struct that was generated with make sysent.
>>>
>>
>> Since 3735348794091372545 is 0x33d69ff1, it looks like the upper
>> word got corrupted somehow. Maybe some part of it got non-atomically
>> assigned? Maybe the wrong word was read? It is hard to tell without
>> code... :)
>>
>
> Userland syscall calling:
>
> killjob(getjid(), SIGINT); //getjid() returns 1 this case, whose type is
> jid_t
>
> Kernel code:
>
> int
> killjob(struct thread *td, struct killjob_args *uap)
> {
> struct jobentry *jp, *jtmp;
> struct procentry *pp, *ptmp;
>
> JOBLIST_bWLOCK;
> LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) {
> if (jp->jid == uap->jid) {
> /* never reached code, comparison always fail because
> of corrupted value */
> }
> }
> JOBLIST_WUNLOCK;
>
> /* not such job */
> td->td_retval[0] = -1;
> return (ENOJOB);
> }
What does struct killjob_args look like?
Is this syscall defined in a module, or an addition to the kernel's
syscalls.master?
Is the user-space 32-bit or 64-bit? What about the kernel?
Thanks,
matthew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange problem with int64_t variables
Em 2010.07.11. 17:33, m...@freebsd.org escreveu:
What does struct killjob_args look like?
It's just what make sysent generated:
+struct killjob_args {
+ char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)];
+ char signal_l_[PADL_(int)]; int signal; char signal_r_[PADR_(int)];
+};
Is this syscall defined in a module, or an addition to the kernel's
syscalls.master?
In syscalls.master:
+ { AS(makenewjob_args), (sy_call_t *)makenewjob, AUE_NULL, NULL, 0, 0,
0, SY_THR_STATIC }, /* 523 = makenewjob */
+ { AS(killjob_args), (sy_call_t *)killjob, AUE_NULL, NULL, 0, 0, 0,
SY_THR_STATIC }, /* 524 = killjob */
+ { 0, (sy_call_t *)getjid, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC },
/* 525 = getjid */
+ { AS(getjlimit_args), (sy_call_t *)getjlimit, AUE_NULL, NULL, 0, 0, 0,
SY_THR_STATIC }, /* 526 = getjlimit */
+ { AS(setjlimit_args), (sy_call_t *)setjlimit, AUE_NULL, NULL, 0, 0, 0,
SY_THR_STATIC }, /* 527 = setjlimit */
Is the user-space 32-bit or 64-bit? What about the kernel?
Both are 32-bit.
Gabor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
*sigpause hanging on 8.x+
So, long story short... I've basically ported the open posix testsuite
to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
sucker hangs on my dev box at home.
I've written a short testcase that demonstrates this. It prints out:
$ ~/test_sigpause
0
And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
as expected).
When I monkey around with libc's compat4.3 stuff a bit, this is what comes up:
$ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
0
before sigemptyset
before _sigsuspend
So it's getting stuck after calling _sigsuspend.
I tried the same thing on a i386 8-STABLE VM and it hangs as well.
I tried applying similar printfs in libthr but it's not hitting that
code at all (it's now responding to SIGTERM though, which is
interesting, but not too interesting to me).
I also wrote similar code that exercised the functionality in
sigsuspend, by calling sigprocmask beforehand, and it works.
Thoughts?
-Garrett
Dev machine:
FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
root@:/usr/obj/usr/src/sys/BAYONETTA amd64
VM:
FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
r207913: Tue May 11 06:21:57 UTC 2010
r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
Index: compat-43/sigcompat.c
===
--- compat-43/sigcompat.c (revision 206173)
+++ compat-43/sigcompat.c (working copy)
@@ -36,6 +36,7 @@
#include "namespace.h"
#include
#include
+#include
#include
#include "un-namespace.h"
#include "libc_private.h"
@@ -102,7 +103,9 @@
{
sigset_t set;
+ printf("before sigemptyset\n");
sigemptyset(&set);
+ printf("before _sigsuspend\n");
set.__bits[0] = mask;
return (_sigsuspend(&set));
}
@@ -111,10 +114,16 @@
xsi_sigpause(int sig)
{
sigset_t set;
+ int rc;
+ printf("before sigemptyset\n");
sigemptyset(&set);
+ printf("before sigaddset\n");
sigaddset(&set, sig);
- return (_sigsuspend(&set));
+ printf("before _sigsuspend\n");
+ rc = (_sigsuspend(&set));
+ printf("after _sigsuspend\n");
+ return rc;
}
int
$ cat ~/test_sigpause.c
#include
#include
int
main (void)
{
printf("0\n");
fflush(stdout);
(void) sigpause(1);
return 0;
}
$ cat ~/test_sigsuspend.c
#include
#include
int
main (void)
{
sigset_t oset;
sigset_t nset;
if (sigprocmask(1, &nset, &oset) == -1)
err(1, "sigprocmask(-1, &nset, &oset)");
if (sigprocmask(-1, &nset, &oset) == -1)
err(1, "sigprocmask(-1, &nset, &oset)");
return (sigsuspend(&nset));
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: *sigpause hanging on 8.x+
On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
> So, long story short... I've basically ported the open posix testsuite
> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
> sucker hangs on my dev box at home.
>
> I've written a short testcase that demonstrates this. It prints out:
>
> $ ~/test_sigpause
> 0
>
> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
> as expected).
>
> When I monkey around with libc's compat4.3 stuff a bit, this is what comes up:
>
> $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
> 0
> before sigemptyset
> before _sigsuspend
>
> So it's getting stuck after calling _sigsuspend.
>
> I tried the same thing on a i386 8-STABLE VM and it hangs as well.
>
> I tried applying similar printfs in libthr but it's not hitting that
> code at all (it's now responding to SIGTERM though, which is
> interesting, but not too interesting to me).
>
> I also wrote similar code that exercised the functionality in
> sigsuspend, by calling sigprocmask beforehand, and it works.
>
> Thoughts?
>
> -Garrett
>
> Dev machine:
> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
> root@:/usr/obj/usr/src/sys/BAYONETTA amd64
> VM:
> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
> r207913: Tue May 11 06:21:57 UTC 2010
> r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
>
> Index: compat-43/sigcompat.c
> ===
> --- compat-43/sigcompat.c (revision 206173)
> +++ compat-43/sigcompat.c (working copy)
> @@ -36,6 +36,7 @@
> #include "namespace.h"
> #include
> #include
> +#include
> #include
> #include "un-namespace.h"
> #include "libc_private.h"
> @@ -102,7 +103,9 @@
> {
> sigset_t set;
>
> + printf("before sigemptyset\n");
> sigemptyset(&set);
> + printf("before _sigsuspend\n");
> set.__bits[0] = mask;
> return (_sigsuspend(&set));
> }
> @@ -111,10 +114,16 @@
> xsi_sigpause(int sig)
> {
> sigset_t set;
> + int rc;
>
> + printf("before sigemptyset\n");
> sigemptyset(&set);
> + printf("before sigaddset\n");
> sigaddset(&set, sig);
> - return (_sigsuspend(&set));
> + printf("before _sigsuspend\n");
> + rc = (_sigsuspend(&set));
> + printf("after _sigsuspend\n");
> + return rc;
> }
>
> int
>
> $ cat ~/test_sigpause.c
> #include
> #include
>
> int
> main (void)
> {
> printf("0\n");
> fflush(stdout);
> (void) sigpause(1);
> return 0;
> }
> $ cat ~/test_sigsuspend.c
> #include
> #include
>
> int
> main (void)
> {
> sigset_t oset;
> sigset_t nset;
> if (sigprocmask(1, &nset, &oset) == -1)
> err(1, "sigprocmask(-1, &nset, &oset)");
> if (sigprocmask(-1, &nset, &oset) == -1)
> err(1, "sigprocmask(-1, &nset, &oset)");
> return (sigsuspend(&nset));
> }
It seems I got a sigmask for sigpause inside the xsi_sigpause() backward.
On the other hand, I do not understand what is your issue with sigpause().
diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
index c3ba30a..bab9d5c 100644
--- a/lib/libc/compat-43/sigcompat.c
+++ b/lib/libc/compat-43/sigcompat.c
@@ -111,9 +111,12 @@ int
xsi_sigpause(int sig)
{
sigset_t set;
+ int error;
- sigemptyset(&set);
- sigaddset(&set, sig);
+ error = _sigprocmask(SIG_BLOCK, NULL, &set);
+ if (error != 0)
+ return (error);
+ sigdelset(&set, sig);
return (_sigsuspend(&set));
}
pgpFi7JxGdk53.pgp
Description: PGP signature
Re: *sigpause hanging on 8.x+
On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
> On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>> So, long story short... I've basically ported the open posix testsuite
>> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
>> sucker hangs on my dev box at home.
>>
>> I've written a short testcase that demonstrates this. It prints out:
>>
>> $ ~/test_sigpause
>> 0
>>
>> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
>> as expected).
>>
>> When I monkey around with libc's compat4.3 stuff a bit, this is what comes
>> up:
>>
>> $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
>> 0
>> before sigemptyset
>> before _sigsuspend
>>
>> So it's getting stuck after calling _sigsuspend.
>>
>> I tried the same thing on a i386 8-STABLE VM and it hangs as well.
>>
>> I tried applying similar printfs in libthr but it's not hitting that
>> code at all (it's now responding to SIGTERM though, which is
>> interesting, but not too interesting to me).
>>
>> I also wrote similar code that exercised the functionality in
>> sigsuspend, by calling sigprocmask beforehand, and it works.
>>
>> Thoughts?
>>
>> -Garrett
>>
>> Dev machine:
>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
>> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
>> root@:/usr/obj/usr/src/sys/BAYONETTA amd64
>> VM:
>> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
>> r207913: Tue May 11 06:21:57 UTC 2010
>> r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
>>
>> Index: compat-43/sigcompat.c
>> ===
>> --- compat-43/sigcompat.c (revision 206173)
>> +++ compat-43/sigcompat.c (working copy)
>> @@ -36,6 +36,7 @@
>> #include "namespace.h"
>> #include
>> #include
>> +#include
>> #include
>> #include "un-namespace.h"
>> #include "libc_private.h"
>> @@ -102,7 +103,9 @@
>> {
>> sigset_t set;
>>
>> + printf("before sigemptyset\n");
>> sigemptyset(&set);
>> + printf("before _sigsuspend\n");
>> set.__bits[0] = mask;
>> return (_sigsuspend(&set));
>> }
>> @@ -111,10 +114,16 @@
>> xsi_sigpause(int sig)
>> {
>> sigset_t set;
>> + int rc;
>>
>> + printf("before sigemptyset\n");
>> sigemptyset(&set);
>> + printf("before sigaddset\n");
>> sigaddset(&set, sig);
>> - return (_sigsuspend(&set));
>> + printf("before _sigsuspend\n");
>> + rc = (_sigsuspend(&set));
>> + printf("after _sigsuspend\n");
>> + return rc;
>> }
>>
>> int
>>
>> $ cat ~/test_sigpause.c
>> #include
>> #include
>>
>> int
>> main (void)
>> {
>> printf("0\n");
>> fflush(stdout);
>> (void) sigpause(1);
>> return 0;
>> }
>> $ cat ~/test_sigsuspend.c
>> #include
>> #include
>>
>> int
>> main (void)
>> {
>> sigset_t oset;
>> sigset_t nset;
>> if (sigprocmask(1, &nset, &oset) == -1)
>> err(1, "sigprocmask(-1, &nset, &oset)");
>> if (sigprocmask(-1, &nset, &oset) == -1)
>> err(1, "sigprocmask(-1, &nset, &oset)");
>> return (sigsuspend(&nset));
>> }
>
> It seems I got a sigmask for sigpause inside the xsi_sigpause() backward.
> On the other hand, I do not understand what is your issue with sigpause().
The negative testcase from the open posix testsuite was setup so that
setting sigpause(-1) would return -1 with EINVAL, according to the
sig* manpages (-1 is an invalid signal of course). That isn't being
triggered with either function today.
0 seems a bit wonky too (it's an invalid signal number).
My bet is that values greater than SIGRTMAX aren't interpreted properly either.
> diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
> index c3ba30a..bab9d5c 100644
> --- a/lib/libc/compat-43/sigcompat.c
> +++ b/lib/libc/compat-43/sigcompat.c
> @@ -111,9 +111,12 @@ int
> xsi_sigpause(int sig)
> {
> sigset_t set;
> + int error;
>
> - sigemptyset(&set);
> - sigaddset(&set, sig);
> + error = _sigprocmask(SIG_BLOCK, NULL, &set);
> + if (error != 0)
> + return (error);
> + sigdelset(&set, sig);
> return (_sigsuspend(&set));
> }
Doesn't this violate the restore clause noted in the manpage?
The xsi_sigpause() function removes sig from the signal mask of the call-
ing process and suspend the calling process until a signal is received.
The xsi_sigpause() function restores the signal mask of the process to
its original state before returning.
So if I had a sigset defined above with sig, then redefined it, I
would be whacking the previous handler by passing in NULL to
_sigprocmask, correct? If so, sigpause has issues too in its
implementation.
There's also some interesting SIGDELSET action going on in libthr's
copy of _sigsuspend's with SIGCANCEL (apparently that's the unofficial
alias for SIGRTMIN as defined by l
Re: elf obj load: skip zero-sized sections early
on 12/07/2010 00:15 Jeff Roberson said the following: > > On Sun, 11 Jul 2010, Andriy Gapon wrote: > >> >> [oops, sorry, this is not a dup - corrected some omissions/mistakes] >> >> on 11/07/2010 14:54 Andriy Gapon said the following: >>> For completeness, here is a patch that simply drops the inline >>> assembly and the >>> comment about it, and GCC-generated assembly and its diff: >>> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch >>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s >>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff >>> >>> As was speculated above, the only thing really changed is section >>> alignment >>> (from 128 to 4). >> >> After making the above analysis I wondered why we require set_pcpu >> section >> alignment at all. After all, it's not used as loaded, data from the >> section >> gets copied into special per-cpu memory areas. So, logically, it's >> those areas >> that need to be aligned, not the section. > > I appreciate your analysis but I don't understand the motivation for > changing working code. Primary reason is that the "working code" produces zero-sized unused/unnecessary pcpu_set sections. See the subject line. As to why I care about those sections - please see the start of this thread. P.S. Short summary: there is no reason to have zero sized sections; some tools either do not expect them or handle them suboptimally. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: *sigpause hanging on 8.x+
On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
> >> So, long story short... I've basically ported the open posix testsuite
> >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
> >> sucker hangs on my dev box at home.
> >>
> >> I've written a short testcase that demonstrates this. It prints out:
> >>
> >> $ ~/test_sigpause
> >> 0
> >>
> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
> >> as expected).
> >>
> >> When I monkey around with libc's compat4.3 stuff a bit, this is what comes
> >> up:
> >>
> >> $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
> >> 0
> >> before sigemptyset
> >> before _sigsuspend
> >>
> >> So it's getting stuck after calling _sigsuspend.
> >>
> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well.
> >>
> >> I tried applying similar printfs in libthr but it's not hitting that
> >> code at all (it's now responding to SIGTERM though, which is
> >> interesting, but not too interesting to me).
> >>
> >> I also wrote similar code that exercised the functionality in
> >> sigsuspend, by calling sigprocmask beforehand, and it works.
> >>
> >> Thoughts?
> >>
> >> -Garrett
> >>
> >> Dev machine:
> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
> >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
> >> root@:/usr/obj/usr/src/sys/BAYONETTA amd64
> >> VM:
> >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
> >> r207913: Tue May 11 06:21:57 UTC 2010
> >> r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
> >>
> >> Index: compat-43/sigcompat.c
> >> ===
> >> --- compat-43/sigcompat.c (revision 206173)
> >> +++ compat-43/sigcompat.c (working copy)
> >> @@ -36,6 +36,7 @@
> >> #include "namespace.h"
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include "un-namespace.h"
> >> #include "libc_private.h"
> >> @@ -102,7 +103,9 @@
> >> {
> >> sigset_t set;
> >>
> >> + printf("before sigemptyset\n");
> >> sigemptyset(&set);
> >> + printf("before _sigsuspend\n");
> >> set.__bits[0] = mask;
> >> return (_sigsuspend(&set));
> >> }
> >> @@ -111,10 +114,16 @@
> >> xsi_sigpause(int sig)
> >> {
> >> sigset_t set;
> >> + int rc;
> >>
> >> + printf("before sigemptyset\n");
> >> sigemptyset(&set);
> >> + printf("before sigaddset\n");
> >> sigaddset(&set, sig);
> >> - return (_sigsuspend(&set));
> >> + printf("before _sigsuspend\n");
> >> + rc = (_sigsuspend(&set));
> >> + printf("after _sigsuspend\n");
> >> + return rc;
> >> }
> >>
> >> int
> >>
> >> $ cat ~/test_sigpause.c
> >> #include
> >> #include
> >>
> >> int
> >> main (void)
> >> {
> >> printf("0\n");
> >> fflush(stdout);
> >> (void) sigpause(1);
> >> return 0;
> >> }
> >> $ cat ~/test_sigsuspend.c
> >> #include
> >> #include
> >>
> >> int
> >> main (void)
> >> {
> >> sigset_t oset;
> >> sigset_t nset;
> >> if (sigprocmask(1, &nset, &oset) == -1)
> >> err(1, "sigprocmask(-1, &nset, &oset)");
> >> if (sigprocmask(-1, &nset, &oset) == -1)
> >> err(1, "sigprocmask(-1, &nset, &oset)");
> >> return (sigsuspend(&nset));
> >> }
> >
> > It seems I got a sigmask for sigpause inside the xsi_sigpause() backward.
> > On the other hand, I do not understand what is your issue with sigpause().
>
> The negative testcase from the open posix testsuite was setup so that
> setting sigpause(-1) would return -1 with EINVAL, according to the
> sig* manpages (-1 is an invalid signal of course). That isn't being
> triggered with either function today.
>
> 0 seems a bit wonky too (it's an invalid signal number).
>
> My bet is that values greater than SIGRTMAX aren't interpreted properly
> either.
I will add these checks, thanks.
>
> > diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
> > index c3ba30a..bab9d5c 100644
> > --- a/lib/libc/compat-43/sigcompat.c
> > +++ b/lib/libc/compat-43/sigcompat.c
> > @@ -111,9 +111,12 @@ int
> > xsi_sigpause(int sig)
> > {
> > sigset_t set;
> > + int error;
> >
> > - sigemptyset(&set);
> > - sigaddset(&set, sig);
> > + error = _sigprocmask(SIG_BLOCK, NULL, &set);
> > + if (error != 0)
> > + return (error);
> > + sigdelset(&set, sig);
> > return (_sigsuspend(&set));
> > }
>
> Doesn't this violate the restore clause noted in the manpage?
>
> The xsi_sigpause() function removes sig from the signal mask of the call-
> ing process and suspend the calling process until a signal is received.
> The xsi_sigpause() function restores the signal mask of the process to
> its origina
Re: *sigpause hanging on 8.x+
2010/7/11 Kostik Belousov :
> On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
>> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov wrote:
>> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>> >> So, long story short... I've basically ported the open posix testsuite
>> >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
>> >> sucker hangs on my dev box at home.
>> >>
>> >> I've written a short testcase that demonstrates this. It prints out:
>> >>
>> >> $ ~/test_sigpause
>> >> 0
>> >>
>> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
>> >> as expected).
>> >>
>> >> When I monkey around with libc's compat4.3 stuff a bit, this is what
>> >> comes up:
>> >>
>> >> $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
>> >> 0
>> >> before sigemptyset
>> >> before _sigsuspend
>> >>
>> >> So it's getting stuck after calling _sigsuspend.
>> >>
>> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well.
>> >>
>> >> I tried applying similar printfs in libthr but it's not hitting that
>> >> code at all (it's now responding to SIGTERM though, which is
>> >> interesting, but not too interesting to me).
>> >>
>> >> I also wrote similar code that exercised the functionality in
>> >> sigsuspend, by calling sigprocmask beforehand, and it works.
>> >>
>> >> Thoughts?
>> >>
>> >> -Garrett
>> >>
>> >> Dev machine:
>> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
>> >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
>> >> root@:/usr/obj/usr/src/sys/BAYONETTA amd64
>> >> VM:
>> >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
>> >> r207913: Tue May 11 06:21:57 UTC 2010
>> >> r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
>> >>
>> >> Index: compat-43/sigcompat.c
>> >> ===
>> >> --- compat-43/sigcompat.c (revision 206173)
>> >> +++ compat-43/sigcompat.c (working copy)
>> >> @@ -36,6 +36,7 @@
>> >> #include "namespace.h"
>> >> #include
>> >> #include
>> >> +#include
>> >> #include
>> >> #include "un-namespace.h"
>> >> #include "libc_private.h"
>> >> @@ -102,7 +103,9 @@
>> >> {
>> >> sigset_t set;
>> >>
>> >> + printf("before sigemptyset\n");
>> >> sigemptyset(&set);
>> >> + printf("before _sigsuspend\n");
>> >> set.__bits[0] = mask;
>> >> return (_sigsuspend(&set));
>> >> }
>> >> @@ -111,10 +114,16 @@
>> >> xsi_sigpause(int sig)
>> >> {
>> >> sigset_t set;
>> >> + int rc;
>> >>
>> >> + printf("before sigemptyset\n");
>> >> sigemptyset(&set);
>> >> + printf("before sigaddset\n");
>> >> sigaddset(&set, sig);
>> >> - return (_sigsuspend(&set));
>> >> + printf("before _sigsuspend\n");
>> >> + rc = (_sigsuspend(&set));
>> >> + printf("after _sigsuspend\n");
>> >> + return rc;
>> >> }
>> >>
>> >> int
>> >>
>> >> $ cat ~/test_sigpause.c
>> >> #include
>> >> #include
>> >>
>> >> int
>> >> main (void)
>> >> {
>> >> printf("0\n");
>> >> fflush(stdout);
>> >> (void) sigpause(1);
>> >> return 0;
>> >> }
>> >> $ cat ~/test_sigsuspend.c
>> >> #include
>> >> #include
>> >>
>> >> int
>> >> main (void)
>> >> {
>> >> sigset_t oset;
>> >> sigset_t nset;
>> >> if (sigprocmask(1, &nset, &oset) == -1)
>> >> err(1, "sigprocmask(-1, &nset, &oset)");
>> >> if (sigprocmask(-1, &nset, &oset) == -1)
>> >> err(1, "sigprocmask(-1, &nset, &oset)");
>> >> return (sigsuspend(&nset));
>> >> }
>> >
>> > It seems I got a sigmask for sigpause inside the xsi_sigpause() backward.
>> > On the other hand, I do not understand what is your issue with sigpause().
>>
>> The negative testcase from the open posix testsuite was setup so that
>> setting sigpause(-1) would return -1 with EINVAL, according to the
>> sig* manpages (-1 is an invalid signal of course). That isn't being
>> triggered with either function today.
>>
>> 0 seems a bit wonky too (it's an invalid signal number).
>>
>> My bet is that values greater than SIGRTMAX aren't interpreted properly
>> either.
>
> I will add these checks, thanks.
Much obliged :)... FWIW sigprocmask fails to do the right thing in
detecting the signal number:
$ ~/test_sigprocmask
signo = -1 result not sane (0 != -1, errno: 0 != EINVAL)
signo = 0 result not sane (0 != -1, errno: 0 != EINVAL)
signo = 1 result sane
signo = 9 result sane
signo = 17 result sane
signo = 65 result sane
signo = 64 result sane
signo = 66 result not sane (0 != -1, errno: 0 != EINVAL)
Would this fix that?
Index: sys/kern/kern_sig.c
===
--- sys/kern/kern_sig.c (revision 206173)
+++ sys/kern/kern_sig.c (working copy)
@@ -988,6 +988,9 @@
struct proc *p;
int error;
+ if (!_SIG_VALID(how))
+ return (-EINVAL);
+
p =
Re: *sigpause hanging on 8.x+
On Sun, Jul 11, 2010 at 3:35 PM, Garrett Cooper wrote:
> 2010/7/11 Kostik Belousov :
>> On Sun, Jul 11, 2010 at 02:30:01PM -0700, Garrett Cooper wrote:
>>> On Sun, Jul 11, 2010 at 2:08 PM, Kostik Belousov
>>> wrote:
>>> > On Sun, Jul 11, 2010 at 12:39:39PM -0700, Garrett Cooper wrote:
>>> >> So, long story short... I've basically ported the open posix testsuite
>>> >> to FreeBSD, and one of the tests tests out sigpause. Unfortunately the
>>> >> sucker hangs on my dev box at home.
>>> >>
>>> >> I've written a short testcase that demonstrates this. It prints out:
>>> >>
>>> >> $ ~/test_sigpause
>>> >> 0
>>> >>
>>> >> And proceeds to be unresponsive to signals (except SIGSTOP / SIGKILL,
>>> >> as expected).
>>> >>
>>> >> When I monkey around with libc's compat4.3 stuff a bit, this is what
>>> >> comes up:
>>> >>
>>> >> $ env LD_LIBRARY_PATH=$PWD:/usr/src/lib/libc/../libthr ~/test_sigpause
>>> >> 0
>>> >> before sigemptyset
>>> >> before _sigsuspend
>>> >>
>>> >> So it's getting stuck after calling _sigsuspend.
>>> >>
>>> >> I tried the same thing on a i386 8-STABLE VM and it hangs as well.
>>> >>
>>> >> I tried applying similar printfs in libthr but it's not hitting that
>>> >> code at all (it's now responding to SIGTERM though, which is
>>> >> interesting, but not too interesting to me).
>>> >>
>>> >> I also wrote similar code that exercised the functionality in
>>> >> sigsuspend, by calling sigprocmask beforehand, and it works.
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> -Garrett
>>> >>
>>> >> Dev machine:
>>> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1
>>> >> r206173:209901M: Sun Jul 11 04:18:42 PDT 2010
>>> >> root@:/usr/obj/usr/src/sys/BAYONETTA amd64
>>> >> VM:
>>> >> FreeBSD starr-bastion.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0
>>> >> r207913: Tue May 11 06:21:57 UTC 2010
>>> >> r...@starr-bastion.localdomain:/usr/obj/usr/src/sys/GENERIC i386
>>> >>
>>> >> Index: compat-43/sigcompat.c
>>> >> ===
>>> >> --- compat-43/sigcompat.c (revision 206173)
>>> >> +++ compat-43/sigcompat.c (working copy)
>>> >> @@ -36,6 +36,7 @@
>>> >> #include "namespace.h"
>>> >> #include
>>> >> #include
>>> >> +#include
>>> >> #include
>>> >> #include "un-namespace.h"
>>> >> #include "libc_private.h"
>>> >> @@ -102,7 +103,9 @@
>>> >> {
>>> >> sigset_t set;
>>> >>
>>> >> + printf("before sigemptyset\n");
>>> >> sigemptyset(&set);
>>> >> + printf("before _sigsuspend\n");
>>> >> set.__bits[0] = mask;
>>> >> return (_sigsuspend(&set));
>>> >> }
>>> >> @@ -111,10 +114,16 @@
>>> >> xsi_sigpause(int sig)
>>> >> {
>>> >> sigset_t set;
>>> >> + int rc;
>>> >>
>>> >> + printf("before sigemptyset\n");
>>> >> sigemptyset(&set);
>>> >> + printf("before sigaddset\n");
>>> >> sigaddset(&set, sig);
>>> >> - return (_sigsuspend(&set));
>>> >> + printf("before _sigsuspend\n");
>>> >> + rc = (_sigsuspend(&set));
>>> >> + printf("after _sigsuspend\n");
>>> >> + return rc;
>>> >> }
>>> >>
>>> >> int
>>> >>
>>> >> $ cat ~/test_sigpause.c
>>> >> #include
>>> >> #include
>>> >>
>>> >> int
>>> >> main (void)
>>> >> {
>>> >> printf("0\n");
>>> >> fflush(stdout);
>>> >> (void) sigpause(1);
>>> >> return 0;
>>> >> }
>>> >> $ cat ~/test_sigsuspend.c
>>> >> #include
>>> >> #include
>>> >>
>>> >> int
>>> >> main (void)
>>> >> {
>>> >> sigset_t oset;
>>> >> sigset_t nset;
>>> >> if (sigprocmask(1, &nset, &oset) == -1)
>>> >> err(1, "sigprocmask(-1, &nset, &oset)");
>>> >> if (sigprocmask(-1, &nset, &oset) == -1)
>>> >> err(1, "sigprocmask(-1, &nset, &oset)");
>>> >> return (sigsuspend(&nset));
>>> >> }
>>> >
>>> > It seems I got a sigmask for sigpause inside the xsi_sigpause() backward.
>>> > On the other hand, I do not understand what is your issue with sigpause().
>>>
>>> The negative testcase from the open posix testsuite was setup so that
>>> setting sigpause(-1) would return -1 with EINVAL, according to the
>>> sig* manpages (-1 is an invalid signal of course). That isn't being
>>> triggered with either function today.
>>>
>>> 0 seems a bit wonky too (it's an invalid signal number).
>>>
>>> My bet is that values greater than SIGRTMAX aren't interpreted properly
>>> either.
>>
>> I will add these checks, thanks.
>
> Much obliged :)... FWIW sigprocmask fails to do the right thing in
> detecting the signal number:
>
> $ ~/test_sigprocmask
> signo = -1 result not sane (0 != -1, errno: 0 != EINVAL)
> signo = 0 result not sane (0 != -1, errno: 0 != EINVAL)
> signo = 1 result sane
> signo = 9 result sane
> signo = 17 result sane
> signo = 65 result sane
> signo = 64 result sane
> signo = 66 result not sane (0 != -1, errno: 0 != EINVAL)
>
> Would this fix that?
>
> Index: sys/kern/kern_sig.c
> ===
Re: *sigpause hanging on 8.x+
2010/7/11 Alexander Kabaev : > On Sun, 11 Jul 2010 15:59:05 -0700 > Garrett Cooper wrote: > >> > + if (!_SIG_VALID(how)) >> > + return (-EINVAL); > > -EINVAL? Smells too much of Linux, try returning EINVAL instead. Wow, I'm batting 1,000 today. Please completely ignore my previous claim about sigprocmask(2) -- I'm screwing up my function calls. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: *sigpause hanging on 8.x+
On Sun, 11 Jul 2010 15:59:05 -0700 Garrett Cooper wrote: > > + if (!_SIG_VALID(how)) > > + return (-EINVAL); -EINVAL? Smells too much of Linux, try returning EINVAL instead. -- Alexander Kabaev signature.asc Description: PGP signature
Re: *sigpause hanging on 8.x+
On Sun, Jul 11, 2010 at 4:19 PM, Garrett Cooper wrote:
> 2010/7/11 Alexander Kabaev :
>> On Sun, 11 Jul 2010 15:59:05 -0700
>> Garrett Cooper wrote:
>>
>>> > + if (!_SIG_VALID(how))
>>> > + return (-EINVAL);
>>
>> -EINVAL? Smells too much of Linux, try returning EINVAL instead.
>
> Wow, I'm batting 1,000 today. Please completely ignore my previous
> claim about sigprocmask(2) -- I'm screwing up my function calls.
So after writing more correct tests, everything's fine with
sig{add,del}set, as expected:
$ cat ~/test_sigaddset.c
#include
#include
#include
#include
#define TEST_SIGADDSET_POS(signo) do { \
printf("signo = %d : ", signo); \
sigemptyset(&set); \
errno = 0; \
rc = sigaddset(&set, signo);\
if (rc != 0) { \
printf("result not sane (%d != 0, errno: %d)\n",\
rc, errno); \
} else \
printf("result sane\n");\
} while (0)
#define TEST_SIGADDSET_NEG(signo) do { \
printf("signo = %d : ", signo); \
sigemptyset(&set); \
errno = 0; \
rc = sigaddset(&set, signo);\
if (rc != -1 || errno != EINVAL) { \
printf("result not sane (%d != -1, "\
"errno: %d != EINVAL)\n", \
rc, errno); \
} else \
printf("result sane\n");\
} while (0)
#define TEST_SIGDELSET_POS(signo) do { \
printf("signo = %d : ", signo); \
sigemptyset(&set); \
errno = 0; \
rc = sigdelset(&set, signo);\
if (rc != 0) { \
printf("result not sane (%d != 0, errno: %d)\n",\
rc, errno); \
} else \
printf("result sane\n");\
} while (0)
#define TEST_SIGDELSET_NEG(signo) do { \
printf("signo = %d : ", signo); \
sigemptyset(&set); \
errno = 0; \
rc = sigdelset(&set, signo);\
if (rc != -1 || errno != EINVAL) { \
printf("result not sane (%d != -1, "\
"errno: %d != EINVAL)\n", \
rc, errno); \
} else \
printf("result sane\n");\
} while (0)
int
main(void)
{
sigset_t set;
int rc;
TEST_SIGADDSET_NEG(-1);
TEST_SIGADDSET_NEG(0);
TEST_SIGADDSET_POS(SIGHUP);
/* The system quietly disallows SIGKILL or SIGSTOP to be blocked. */
TEST_SIGADDSET_POS(SIGKILL);
TEST_SIGADDSET_POS(SIGSTOP);
TEST_SIGADDSET_POS(SIGRTMIN-1);
TEST_SIGADDSET_POS(SIGRTMIN);
TEST_SIGADDSET_POS(SIGRTMIN+1);
TEST_SIGADDSET_POS(SIGRTMAX);
TEST_SIGDELSET_NEG(-1);
TEST_SIGDELSET_NEG(0);
TEST_SIGDELSET_POS(SIGHUP);
/* The system quietly disallows SIGKILL or SIGSTOP to be blocked. */
TEST_SIGDELSET_POS(SIGKILL);
TEST_SIGDELSET_POS(SIGSTOP);
TEST_SIGDELSET_POS(SIGRTMIN-1);
TEST_SIGDELSET_POS(SIGRTMIN);
TEST_SIGDELSET_POS(SIGRTMIN+1);
TEST_SIGDELSET_POS(SIGRTMAX);
return (0);
}
$ ~/test_sigadddelset
signo = -1 : result sane
signo = 0 : result sane
signo = 1 : result sane
signo = 9 : result sane
signo = 17 : result sane
signo = 64 : result sane
signo = 65 : result sane
signo = 66 : result sane
signo = 126 : result sane
signo = -1 : result sane
signo = 0 : result sane
signo = 1 : result sane
Re: mallinfo equivalent on FreeBSD
Hi, On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote: > Hello, > I would like to know the memory usage (total virtual memory) inside a > process and make decisions accordingly. > To be more specific, I am using BerkeleyDB backed set or std::set (C++ > STL) depending on my current memory usage > as my process will need to run in a resource constrained environment. > By the way, this is user mode application. > > Some things I am considering/tried: > 1. GNU/Linux has mallinfo and I had my code working based on the > information I get from the call. Could anyone please help and throw some light on this topic (mallinfo) equivalent. I am stuck and need resolve this soon. In short, I need to find out the virtual memory used (mapped to the process's address space) in a light weight fashion so that I can make some decision based on it. with best regards, dhruva ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mallinfo equivalent on FreeBSD
On 12/07/2010, at 12:40, dhruva wrote: > On Wed, Jun 30, 2010 at 12:49 PM, dhruva wrote: >> Hello, >> I would like to know the memory usage (total virtual memory) inside a >> process and make decisions accordingly. >> To be more specific, I am using BerkeleyDB backed set or std::set (C++ >> STL) depending on my current memory usage >> as my process will need to run in a resource constrained environment. >> By the way, this is user mode application. >> >> Some things I am considering/tried: >> 1. GNU/Linux has mallinfo and I had my code working based on the >> information I get from the call. > > Could anyone please help and throw some light on this topic (mallinfo) > equivalent. I am stuck and need > resolve this soon. In short, I need to find out the virtual memory > used (mapped to the process's address space) > in a light weight fashion so that I can make some decision based on it. Can't you use getrusage to find that out? As for system wide stats, I think you could look at sysctl, specifically the vm tree. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] SUBDIR_OVERRIDE `optimization'
On Fri, Jul 09, 2010 at 07:56:37AM -0700, Garrett Cooper wrote:
> (Let's try this again with the right email address)
> Something simple that I noticed a while back when I was reviewing
> the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the
> conditional feature checks, which sets the value of SUBDIRS to the
> user defined value. So instead of going through the conditionals, one
> could just cut to the chase and set SUBDIRS to SUBDIRS_OVERRIDE,
> otherwise detect the conditional directories to include in
> Makefile.inc1.
> Thanks!
> -Garrett
>
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 209684)
> +++ Makefile.inc1 (working copy)
> @@ -41,6 +41,9 @@
> # use that new version. And the new (dynamically-linked) /bin/sh
> # will expect to find appropriate libraries in /lib and /libexec.
> #
> +.if defined(SUBDIR_OVERRIDE)
> +SUBDIR= ${SUBDIR_OVERRIDE}
> +.else
> SUBDIR= share/info lib libexec
> SUBDIR+=bin
> .if ${MK_GAMES} != "no"
> @@ -79,8 +82,6 @@
> .endif
> .endfor
>
> -.if defined(SUBDIR_OVERRIDE)
> -SUBDIR= ${SUBDIR_OVERRIDE}
> .endif
>
> .if defined(NOCLEAN)
SUBDIR_OVERRIDE is mainly for FreeBSD src/ builders (to quickly
check with "buildworld" a particular bit of a tree), and is thus
rarely used, so this change would be an optimization for the
uncommon case. Having said that, I don't mind if you commit it,
if you like.
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
