|
From: Nicholas N. <nj...@cs...> - 2005-11-12 18:52:50
|
Hi, I get this problem building memcheck/tests/stack_switch.c: ~/grind/trunk2/memcheck/tests] mq check Making check in . stack_switch.c: In function 'main': stack_switch.c:40: error: 'CLONE_THREAD' undeclared (first use in this function) stack_switch.c:40: error: (Each undeclared identifier is reported only once stack_switch.c:40: error: for each function it appears in.) make[2]: *** [stack_switch.o] Error 1 make[1]: *** [check-am] Error 2 make: *** [check-recursive] Error 1 On my machine bits/sched.h (which gets pulled into sched.h) does not defined CLONE_THREAD. But linux/sched.h does. Should we #include <linux/sched.h> as well? Nick |
|
From: Tom H. <to...@co...> - 2005-11-12 18:56:52
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> I get this problem building memcheck/tests/stack_switch.c:
>
> ~/grind/trunk2/memcheck/tests] mq check
> Making check in .
> stack_switch.c: In function 'main':
> stack_switch.c:40: error: 'CLONE_THREAD' undeclared (first use in this
> function)
> stack_switch.c:40: error: (Each undeclared identifier is reported only
> once
> stack_switch.c:40: error: for each function it appears in.)
> make[2]: *** [stack_switch.o] Error 1
> make[1]: *** [check-am] Error 2
> make: *** [check-recursive] Error 1
>
> On my machine bits/sched.h (which gets pulled into sched.h) does not
> defined CLONE_THREAD. But linux/sched.h does. Should we #include
> <linux/sched.h> as well?
It's not ideal as that is a kernel header, but it might be necessary.
It looks like some of my test machines have the same problem actually.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-12 19:07:09
|
> > On my machine bits/sched.h (which gets pulled into sched.h) does not > > defined CLONE_THREAD. But linux/sched.h does. Should we #include > > <linux/sched.h> as well? > > It's not ideal as that is a kernel header, but it might be necessary. Can we get away with flags = .... #if defined(CLONE_THREAD) flags |= CLONE_THREAD; #endif ? Or does that make a nonsense of the test if it isn't defined? I'd prefer to avoid depending on more kernel headers if we can. J |
|
From: Nicholas N. <nj...@cs...> - 2005-11-12 19:39:00
|
On Sat, 12 Nov 2005, Tom Hughes wrote: >> On my machine bits/sched.h (which gets pulled into sched.h) does not >> defined CLONE_THREAD. But linux/sched.h does. Should we #include >> <linux/sched.h> as well? > > It's not ideal as that is a kernel header, but it might be necessary. > > It looks like some of my test machines have the same problem actually. Or we could #define it ourselves if missing. N |
|
From: Nicholas N. <nj...@cs...> - 2005-11-15 15:22:40
|
On Sat, 12 Nov 2005, Nicholas Nethercote wrote: > I get this problem building memcheck/tests/stack_switch.c: I fixed this yesterday. Is there much difference between stack_switch.c and stack_changes.c? On my machine stack_changes.c fails badly (and always has) -- I get 8 or 9 invalid read/write errors. Nick |
|
From: Tom H. <to...@co...> - 2005-11-15 15:50:42
|
-- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2005-11-15 15:51:21
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sat, 12 Nov 2005, Nicholas Nethercote wrote:
>
>> I get this problem building memcheck/tests/stack_switch.c:
>
> I fixed this yesterday. Is there much difference between
> stack_switch.c and stack_changes.c? On my machine stack_changes.c
> fails badly (and always has) -- I get 8 or 9 invalid read/write errors.
I have no idea what stack_changes is testing - stack_switch I wrote
to test that bug I committed the patch for last week.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Robert W. <rj...@du...> - 2005-11-17 04:52:14
|
> I have no idea what stack_changes is testing - stack_switch I wrote > to test that bug I committed the patch for last week. stack_changes is checking the libc context calls (setcontext, etc.) and checks that Valgrind notices their stack changes properly. This has nothing to do with the clone checks that you're doing in stack_switch.=20 Perhaps both names should be a bit more descriptive to describe their functionality. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. "We bring dead things to life" |
|
From: Nicholas N. <nj...@cs...> - 2005-11-17 19:23:34
|
On Wed, 16 Nov 2005, Robert Walsh wrote: >> I have no idea what stack_changes is testing - stack_switch I wrote >> to test that bug I committed the patch for last week. > > stack_changes is checking the libc context calls (setcontext, etc.) and > checks that Valgrind notices their stack changes properly. This has > nothing to do with the clone checks that you're doing in stack_switch. > Perhaps both names should be a bit more descriptive to describe their > functionality. Or some comments could be added at the top of the .c files. More comments in a lot of the regtests explaining what they are testing for would be welcome... some of them say "this is a regtest for bug #12345 which was causing failure X" which is good... Nick |