You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:57:17
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >> Don't know if there is much need for it, but it might be possible to >> make all pages that have PROT_EXEC | PROT_WRITE access >> read/execute-only and trap writes to these pages to automatically >> detect the situation. > > That would catch some of them. But the problem, AFAICT, with all > self-modifying code detection schemes is how to handle code on the > stack. For example, GCC generates snippets of code on the stack when > using nested functions. What? I thought this is highly undefined or at least deprecated, and with NX-aware processores and kernels it will no longer work. > > N > Sebastian |
|
From: Tom H. <th...@cy...> - 2004-08-30 19:50:12
|
CVS commit by thughes:
Add support for POSIIX clocks and timers.
M +105 -14 vg_syscalls.c 1.131
--- valgrind/coregrind/vg_syscalls.c #1.130:1.131
@@ -5315,17 +5315,4 @@ POST(adjtimex)
}
-PRE(clock_gettime)
-{
- /* int clock_gettime(clockid_t clk_id, struct timespec *tp); */
- MAYBE_PRINTF("clock_gettime(%d, %p)\n" ,arg1,arg2);
- SYSCALL_TRACK(pre_mem_write, tid, "clock_gettime(tp)",
- arg2, sizeof(struct timespec));
-}
-
-POST(clock_gettime)
-{
- VG_TRACK( post_mem_write, arg2, sizeof(struct timespec) );
-}
-
PRE(utimes)
{
@@ -5770,4 +5757,99 @@ POST(mq_getsetattr)
}
+PRE(timer_create)
+{
+ /* int timer_create(clockid_t clock_id, struct sigevent *restrict evp,
+ timer_t *restrict timerid); */
+ MAYBE_PRINTF("timer_create( %d, %p, %p )\n", arg1,arg2,arg3);
+ if (arg2 != 0)
+ SYSCALL_TRACK( pre_mem_read, tid, "timer_create(evp)", arg2,
+ sizeof(struct sigevent) );
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_create(timerid)", arg3,
+ sizeof(timer_t) );
+}
+
+POST(timer_create)
+{
+ VG_TRACK( post_mem_write, arg3, sizeof(timer_t) );
+}
+
+PRE(timer_settime)
+{
+ /* int timer_settime(timer_t timerid, int flags,
+ const struct itimerspec *restrict value,
+ struct itimerspec *restrict ovalue); */
+ MAYBE_PRINTF("timer_settime( %p, %d, %p, %p )\n", arg1,arg2,arg3,arg4);
+ SYSCALL_TRACK( pre_mem_read, tid, "timer_settime(value)", arg3,
+ sizeof(struct vki_itimerspec) );
+ if (arg4 != 0)
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_settime(ovalue)", arg4,
+ sizeof(struct vki_itimerspec) );
+}
+
+POST(timer_settime)
+{
+ if (arg4 != 0)
+ VG_TRACK( post_mem_write, arg4, sizeof(struct vki_itimerspec) );
+}
+
+PRE(timer_gettime)
+{
+ /* int timer_gettime(timer_t timerid, struct itimerspec *value); */
+ MAYBE_PRINTF("timer_gettime( %p, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_gettime(value)", arg2,
+ sizeof(struct vki_itimerspec));
+}
+
+POST(timer_gettime)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct vki_itimerspec) );
+}
+
+PRE(timer_getoverrun)
+{
+ /* int timer_getoverrun(timer_t timerid); */
+ MAYBE_PRINTF("timer_getoverrun( %p )\n", arg1);
+}
+
+PRE(timer_delete)
+{
+ /* int timer_delete(timer_t timerid); */
+ MAYBE_PRINTF("timer_delete( %p )\n", arg1);
+}
+
+PRE(clock_settime)
+{
+ /* int clock_settime(clockid_t clk_id, const struct timespec *tp); */
+ MAYBE_PRINTF("clock_settime( %d, %p )\n", arg1,arg2);
+ SYSCALL_TRACK(pre_mem_read, tid, "clock_gettime(tp)",
+ arg2, sizeof(struct timespec) );
+}
+
+PRE(clock_gettime)
+{
+ /* int clock_gettime(clockid_t clk_id, struct timespec *tp); */
+ MAYBE_PRINTF("clock_gettime( %d, %p )\n" , arg1,arg2);
+ SYSCALL_TRACK(pre_mem_write, tid, "clock_gettime(tp)",
+ arg2, sizeof(struct timespec) );
+}
+
+POST(clock_gettime)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct timespec) );
+}
+
+PRE(clock_getres)
+{
+ /* int clock_getres(clockid_t clk_id, struct timespec *res); */
+ MAYBE_PRINTF("clock_getres( %d, %p )\n" , arg1,arg2);
+ SYSCALL_TRACK(pre_mem_write, tid, "clock_getres(res)",
+ arg2, sizeof(struct timespec) );
+}
+
+POST(clock_getres)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct timespec) );
+}
+
struct sys_info {
UInt flags;
@@ -6014,5 +6096,4 @@ static const struct sys_info sys_info[]
SYSBA(adjtimex, 0),
SYSBA(mmap2, 0),
- SYSBA(clock_gettime, 0),
SYSBA(futex, MayBlock),
SYSB_(acct, 0),
@@ -6042,4 +6123,14 @@ static const struct sys_info sys_info[]
SYSBA(mq_getsetattr, 0),
+ SYSBA(timer_create, 0),
+ SYSBA(timer_settime, 0),
+ SYSBA(timer_gettime, 0),
+ SYSB_(timer_getoverrun, 0),
+ SYSB_(timer_delete, 0),
+
+ SYSB_(clock_settime, 0),
+ SYSBA(clock_gettime, 0),
+ SYSBA(clock_getres, 0),
+
#if !SIGNAL_SIMULATION
SYSBA(sigaltstack, 0),
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:46:09
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: > Don't know if there is much need for it, but it might be possible to make all > pages that have PROT_EXEC | PROT_WRITE access read/execute-only and trap > writes to these pages to automatically detect the situation. That would catch some of them. But the problem, AFAICT, with all self-modifying code detection schemes is how to handle code on the stack. For example, GCC generates snippets of code on the stack when using nested functions. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:42:22
|
On Mon, 30 Aug 2004, Nicholas Nethercote wrote: > CVS commit by nethercote: > > Print a message if shadow memory cannot be allocated, rather than just > asserting. That's my last change before the release; I won't touch anything else. N |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:40:20
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >> Now that the timer code works (thanks for the fast responses!), I have >> a problem with valgrind itself. The program I work on is also a >> JIT[1], so it could also be an obscure prefetch queue problem or so, >> but the program definitely behaves differently when being valgrinded. >> (I read the "Limitations" section of the documentation, and found >> nothing that valgrind can't handle self-modifying code, so I assume it >> can.) > > Hmm, then that section of the manual should be changed. Ok, that explains the problem. > > Valgrind can handle dynamically-generated code just fine. However, if > you regenerate code over the top of old code (ie. at the same memory > addresses) Valgrind will not realise the code has changed, and will run > its old translations, which will be out-of-date. So you need to use the > VALGRIND_DISCARD_TRANSLATIONS client request in that case. Don't know if there is much need for it, but it might be possible to make all pages that have PROT_EXEC | PROT_WRITE access read/execute-only and trap writes to these pages to automatically detect the situation. But anyway, I'll test if using VALGRIND_DISCARD_TRANSLATIONS helps. >> Since my JIT has the nice property, that I can run the translated code >> and a slower interpreter concurrently and compare the results after >> each instruction, I was able to spot the problem -- but I don't >> understand how the code in question could ever be misinterpreted. > > > Yes, that's a very nice feature to have :) > >> On this >> http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs >> page I saw some nice debug output of the translated code of valgrind. >> Is there a runtime option (like the VALGRIND_XXX macros) to >> conditionally turn on this debugging output when my program gets near >> the suspicious code? Or should I use the "--stop-after=" method to >> narrow down to the BB in question? > > --stop-after doesn't exist any more, unfortunately. Use --trace-codegen > to get the debug output (try --trace-codegen=10000 to begin with). That > prints out all the code; if you only want some, you can crudely adjust > the point at which code starts being printed via the > 'notrace_until_limit' variable in vg_translate.c. Well, I don't think it's still necessary since my assumption that valgrind can handle the self-modifying code were wrong. > > HTH > > N > Sebastian |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:36:54
|
CVS commit by nethercote:
Print a message if shadow memory cannot be allocated, rather than just
asserting.
M +7 -1 vg_main.c 1.198 [POSSIBLY UNSAFE: printf]
--- valgrind/coregrind/vg_main.c #1.197:1.198
@@ -495,5 +495,11 @@ static void layout_remaining_space(Addr
vres = mmap((char *)VG_(shadow_base), shadow_size, PROT_NONE,
MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
- vg_assert((void*)-1 != vres);
+ if ((void*)-1 == vres) {
+ fprintf(stderr,
+ "valgrind: Couldn't allocate address space for shadow memory\n"
+ "valgrind: Are you using a kernel with a small user address space,\n"
+ "valgrind: or do you have your virtual memory size limited?\n");
+ exit(1);
+ }
}
}
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:32:00
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: > Now that the timer code works (thanks for the fast responses!), I have a > problem with valgrind itself. The program I work on is also a JIT[1], so it > could also be an obscure prefetch queue problem or so, but the program > definitely behaves differently when being valgrinded. (I read the > "Limitations" section of the documentation, and found nothing that valgrind > can't handle self-modifying code, so I assume it can.) Hmm, then that section of the manual should be changed. Valgrind can handle dynamically-generated code just fine. However, if you regenerate code over the top of old code (ie. at the same memory addresses) Valgrind will not realise the code has changed, and will run its old translations, which will be out-of-date. So you need to use the VALGRIND_DISCARD_TRANSLATIONS client request in that case. > Since my JIT has the nice property, that I can run the translated code and a > slower interpreter concurrently and compare the results after each > instruction, I was able to spot the problem -- but I don't understand how the > code in question could ever be misinterpreted. Yes, that's a very nice feature to have :) > On this > http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs > page I saw some nice debug output of the translated code of valgrind. Is > there a runtime option (like the VALGRIND_XXX macros) to conditionally turn > on this debugging output when my program gets near the suspicious code? Or > should I use the "--stop-after=" method to narrow down to the BB in question? --stop-after doesn't exist any more, unfortunately. Use --trace-codegen to get the debug output (try --trace-codegen=10000 to begin with). That prints out all the code; if you only want some, you can crudely adjust the point at which code starts being printed via the 'notrace_until_limit' variable in vg_translate.c. HTH N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:24:35
|
On Mon, 30 Aug 2004, Tom Hughes wrote: >>> Ok, folks, this is the final call for 2.2.0. I've updated NEWS, >>> hopefully appropriately. Let me know if there's anything else >>> to go in. Nick, I'm assuming you'll commit your fix for #78765. Done. >>> I'll update docs, version numbers, etc, later this evening. >> >> If the timer_* support code is ok, it would be cool if it made it into >> the release. > > If people are happy for it to go in - it's only some system call > wrapper so can't break much - then I'll commit it. Fine by me. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:21:54
|
On Mon, 30 Aug 2004, Julian Seward wrote: > +70587 Add timestamps to Valgrind output? (wishlist) This is worth mentioning at the top, as it does affect users. N |
|
From: Eric E. <eri...@fr...> - 2004-08-30 19:19:48
|
Julian Seward wrote: > Ok, folks, this is the final call for 2.2.0. I've updated NEWS, Mmmmm. Still my dwarf2 updates + small updates for Valgui ? Never mind I try. Could people who would be interested but had no time to have a look at it send me an email ? Did some people have a look, I didn't get many feedback (but didn't ask for, though....) Now it's gonna be a bit late :-P Cheers -- Eric |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 19:18:08
|
Hi! Now that the timer code works (thanks for the fast responses!), I have a problem with valgrind itself. The program I work on is also a JIT[1], so it could also be an obscure prefetch queue problem or so, but the program definitely behaves differently when being valgrinded. (I read the "Limitations" section of the documentation, and found nothing that valgrind can't handle self-modifying code, so I assume it can.) Since my JIT has the nice property, that I can run the translated code and a slower interpreter concurrently and compare the results after each instruction, I was able to spot the problem -- but I don't understand how the code in question could ever be misinterpreted. On this http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs page I saw some nice debug output of the translated code of valgrind. Is there a runtime option (like the VALGRIND_XXX macros) to conditionally turn on this debugging output when my program gets near the suspicious code? Or should I use the "--stop-after=" method to narrow down to the BB in question? Sebastian -- [1] PearPC, http://pearpc.sf.net |
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 19:15:35
|
CVS commit by nethercote:
Avoid divisions by zero. This fixes bug 78765.
Also renamed two of the XPt fields so that things are clearer.
M +93 -73 ms_main.c 1.14
--- valgrind/massif/ms_main.c #1.13:1.14
@@ -101,11 +101,11 @@ struct _XPt {
// which contexts to include at each census point.
// !!! top-XPTs only !!!
- ULong spacetime;
+ ULong approx_ST;
- // spacetime2 is an exact space.time calculation done at the end, and
+ // exact_ST_dbld is an exact space.time calculation done at the end, and
// used in the results.
// Note that it is *doubled*, to avoid rounding errors.
// !!! not used for 'alloc_xpt' !!!
- ULong spacetime2;
+ ULong exact_ST_dbld;
// n_children and max_children are integers; a very big program might
@@ -121,5 +121,5 @@ struct _XPt {
// in the snapshot. The snapshot contains all the XTree's XPts, not in a
// tree structure, but flattened into an array. This flat snapshot is used
-// at the end for computing spacetime2 for each XPt.
+// at the end for computing exact_ST_dbld for each XPt.
//
// Graph resolution, x-axis: no point having more than about 200 census
@@ -370,6 +370,6 @@ static XPt* new_XPt(Addr eip, XPt* paren
xpt->curr_space = 0;
- xpt->spacetime = 0;
- xpt->spacetime2 = 0;
+ xpt->approx_ST = 0;
+ xpt->exact_ST_dbld = 0;
xpt->parent = parent;
@@ -439,6 +439,6 @@ static XPt* get_XCon( ThreadId tid, Bool
// XPt we return is (now and forever) a bottom-XPt. If the returned XPt
// wasn't a bottom-XPt (now or later) it would cause problems later (eg.
- // the parent's spacetime wouldn't be equal to the total of the
- // childrens' spacetimes).
+ // the parent's approx_ST wouldn't be equal [or almost equal] to the
+ // total of the childrens' approx_STs).
eips[ n_eips++ ] = 0xffffffff;
@@ -537,16 +537,16 @@ static void update_XCon(XPt* xpt, Int sp
// Actually want a reverse sort, biggest to smallest
-static Int XPt_cmp_spacetime(void* n1, void* n2)
+static Int XPt_cmp_approx_ST(void* n1, void* n2)
{
XPt* xpt1 = *(XPt**)n1;
XPt* xpt2 = *(XPt**)n2;
- return (xpt1->spacetime < xpt2->spacetime ? 1 : -1);
+ return (xpt1->approx_ST < xpt2->approx_ST ? 1 : -1);
}
-static Int XPt_cmp_spacetime2(void* n1, void* n2)
+static Int XPt_cmp_exact_ST_dbld(void* n1, void* n2)
{
XPt* xpt1 = *(XPt**)n1;
XPt* xpt2 = *(XPt**)n2;
- return (xpt1->spacetime2 < xpt2->spacetime2 ? 1 : -1);
+ return (xpt1->exact_ST_dbld < xpt2->exact_ST_dbld ? 1 : -1);
}
@@ -859,10 +859,10 @@ static UInt get_xtree_size(XPt* xpt, UIn
UInt i;
-// VG_(printf)("%4d ", xpt->curr_space);
+ // If no memory allocated at all, nothing interesting to record.
+ if (alloc_xpt->curr_space == 0) return 0;
- // If this one has size zero, all the children will be size zero too, so
- // nothing interesting to record.
-// if (0 != xpt->curr_space || 0 == ix) {
- if (xpt->curr_space / (double)alloc_xpt->curr_space > 0.002 || 0 == ix) {
+ // Ignore sub-XTrees that account for a miniscule fraction of current
+ // allocated space.
+ if (xpt->curr_space / (double)alloc_xpt->curr_space > 0.002) {
ix++;
@@ -879,12 +879,13 @@ UInt do_space_snapshot(XPt xpt[], XTreeS
UInt i;
- // Snapshot this XPt, if non-zero space, or the first one
-// if (0 != xpt->curr_space || 0 == ix) {
- if (xpt->curr_space / (double)alloc_xpt->curr_space > 0.002 || 0 == ix) {
+ // Structure of this function mirrors that of get_xtree_size().
+
+ if (alloc_xpt->curr_space == 0) return 0;
+
+ if (xpt->curr_space / (double)alloc_xpt->curr_space > 0.002) {
xtree_snapshot[ix].xpt = xpt;
xtree_snapshot[ix].space = xpt->curr_space;
ix++;
- // Snapshot all (non-zero) descendent XPts
for (i = 0; i < xpt->n_children; i++)
ix = do_space_snapshot(xpt->children[i], xtree_snapshot, ix);
@@ -1008,13 +1009,13 @@ static void hp_census(void)
: MAX_SNAPSHOTS); // max out
- // Update .spacetime field (approximatively) for all top-XPts.
+ // Update .approx_ST field (approximatively) for all top-XPts.
// We *do not* do it for any non-top-XPTs.
for (i = 0; i < alloc_xpt->n_children; i++) {
XPt* top_XPt = alloc_xpt->children[i];
- top_XPt->spacetime += top_XPt->curr_space * ms_time_since_prev;
+ top_XPt->approx_ST += top_XPt->curr_space * ms_time_since_prev;
}
- // Sort top-XPts by spacetime2 field.
+ // Sort top-XPts by approx_ST field.
VG_(ssort)(alloc_xpt->children, alloc_xpt->n_children, sizeof(XPt*),
- XPt_cmp_spacetime);
+ XPt_cmp_approx_ST);
VGP_PUSHCC(VgpCensusHeap);
@@ -1024,13 +1025,19 @@ static void hp_census(void)
// Nb: the xtree_size count/snapshot buffer allocation, and the actual
// snapshot, take similar amounts of time (measured with the
- // millesecond counter).
+ // millisecond counter).
for (i = 0; i < K; i++) {
UInt xtree_size, xtree_size2;
-// VG_(printf)("%7u ", alloc_xpt->children[i]->spacetime);
- // Count how many XPts are in the XTree; make array of that size
- // (+1 for zero termination, which calloc() does for us).
+// VG_(printf)("%7u ", alloc_xpt->children[i]->approx_ST);
+ // Count how many XPts are in the XTree
VGP_PUSHCC(VgpCensusTreeSize);
xtree_size = get_xtree_size( alloc_xpt->children[i], 0 );
VGP_POPCC(VgpCensusTreeSize);
+
+ // If no XPts counted (ie. alloc_xpt.curr_space==0 or XTree
+ // insignificant) then don't take any more snapshots.
+ if (0 == xtree_size) break;
+
+ // Make array of the appropriate size (+1 for zero termination,
+ // which calloc() does for us).
census->xtree_snapshots[i] =
VG_(calloc)(xtree_size+1, sizeof(XPtSnapshot));
@@ -1042,5 +1049,5 @@ static void hp_census(void)
// XTree into the snapshot array, along with pointers to the XPts.
// (Except for ones with curr_space==0, which wouldn't contribute
- // to the final spacetime2 calculation anyway; excluding them
+ // to the final exact_ST_dbld calculation anyway; excluding them
// saves a lot of memory and up to 40% time with big --depth valus.
VGP_PUSHCC(VgpCensusSnapshot);
@@ -1180,5 +1187,5 @@ void SK_(pre_clo_init)()
VGP_(register_profile_event)(VgpCensusTreeSize, "census-treesize");
VGP_(register_profile_event)(VgpUpdateXCon, "update-XCon");
- VGP_(register_profile_event)(VgpCalcSpacetime2, "calc-spacetime2");
+ VGP_(register_profile_event)(VgpCalcSpacetime2, "calc-exact_ST_dbld");
VGP_(register_profile_event)(VgpPrintHp, "print-hp");
VGP_(register_profile_event)(VgpPrintXPts, "print-XPts");
@@ -1214,6 +1221,6 @@ UCodeBlock* SK_(instrument)(UCodeBlock*
/*------------------------------------------------------------*/
-// Although we've been calculating spacetime along the way, because the
-// earlier calculations were done at a finer timescale, the .spacetime field
+// Although we've been calculating space-time along the way, because the
+// earlier calculations were done at a finer timescale, the .approx_ST field
// might not agree with what hp2ps sees, because we've thrown away some of
// the information. So recompute it at the scale that hp2ps sees, so we can
@@ -1222,5 +1229,5 @@ UCodeBlock* SK_(instrument)(UCodeBlock*
// that get printed in the .hp file, so it's cheap.
//
-// The spacetime calculation:
+// The approx_ST calculation:
// ( a[0]*d(0,1) + a[1]*(d(0,1) + d(1,2)) + ... + a[N-1]*d(N-2,N-1) ) / 2
// where
@@ -1237,9 +1244,9 @@ UCodeBlock* SK_(instrument)(UCodeBlock*
// census time is easy.
//
-// Each heap calculation gets added to its context's spacetime2 field.
+// Each heap calculation gets added to its context's exact_ST_dbld field.
// The ULong* values are all running totals, hence the use of "+=" everywhere.
// This does the calculations for a single census.
-static void calc_spacetime2b(Census* census, UInt d_t1_t2,
+static void calc_exact_ST_dbld2(Census* census, UInt d_t1_t2,
ULong* twice_heap_ST,
ULong* twice_heap_admin_ST,
@@ -1252,12 +1259,13 @@ static void calc_spacetime2b(Census* cen
if (clo_heap) {
for (i = 0; NULL != census->xtree_snapshots[i]; i++) {
- // Compute total heap spacetime2 for the entire XTree using only the
- // top-XPt (the first XPt in xtree_snapshot).
+ // Compute total heap exact_ST_dbld for the entire XTree using only
+ // the top-XPt (the first XPt in xtree_snapshot).
*twice_heap_ST += d_t1_t2 * census->xtree_snapshots[i][0].space;
- // Increment spacetime2 for every XPt in xtree_snapshot (inc. top one)
+ // Increment exact_ST_dbld for every XPt in xtree_snapshot (inc.
+ // top one)
for (j = 0; NULL != census->xtree_snapshots[i][j].xpt; j++) {
xpt_snapshot = & census->xtree_snapshots[i][j];
- xpt_snapshot->xpt->spacetime2 += d_t1_t2 * xpt_snapshot->space;
+ xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space;
}
}
@@ -1275,5 +1283,5 @@ static void calc_spacetime2b(Census* cen
// This does the calculations for all censi.
-static void calc_spacetime2(ULong* heap2, ULong* heap_admin2, ULong* stack2)
+static void calc_exact_ST_dbld(ULong* heap2, ULong* heap_admin2, ULong* stack2)
{
UInt i, N = curr_census;
@@ -1288,13 +1296,13 @@ static void calc_spacetime2(ULong* heap2
return;
- calc_spacetime2b( &censi[0], censi[1].ms_time - censi[0].ms_time,
+ calc_exact_ST_dbld2( &censi[0], censi[1].ms_time - censi[0].ms_time,
heap2, heap_admin2, stack2 );
for (i = 1; i <= N-2; i++) {
- calc_spacetime2b( & censi[i], censi[i+1].ms_time - censi[i-1].ms_time,
+ calc_exact_ST_dbld2( & censi[i], censi[i+1].ms_time - censi[i-1].ms_time,
heap2, heap_admin2, stack2 );
}
- calc_spacetime2b( & censi[N-1], censi[N-1].ms_time - censi[N-2].ms_time,
+ calc_exact_ST_dbld2( & censi[N-1], censi[N-1].ms_time - censi[N-2].ms_time,
heap2, heap_admin2, stack2 );
// Now get rid of the halves. May lose a 0.5 on each, doesn't matter.
@@ -1499,4 +1507,5 @@ static Char* make_perc(ULong spacetime,
UInt p = 10;
+ sk_assert(0 != total_spacetime);
percentify(spacetime * 100 * p / total_spacetime, p, 5, mbuf);
return mbuf;
@@ -1561,27 +1570,33 @@ static void pp_all_XPts2(Int fd, Queue*
Char* depth = ( is_HTML ? "<code>--depth</code>" : "--depth" );
+ if (total_spacetime == 0) {
+ SPRINTF(buf, "(No heap memory allocated)\n");
+ return;
+ }
+
+
SPRINTF(buf, "== %d ===========================%s\n", L, maybe_br);
while (NULL != (xpt = (XPt*)dequeue(q))) {
- // Check that non-top-level XPts have a zero .spacetime field.
- if (xpt->parent != alloc_xpt) sk_assert( 0 == xpt->spacetime );
+ // Check that non-top-level XPts have a zero .approx_ST field.
+ if (xpt->parent != alloc_xpt) sk_assert( 0 == xpt->approx_ST );
- // Check that the sum of all children .spacetime2s equals parent's
- // (unless alloc_xpt, when it should == 0).
+ // Check that the sum of all children .exact_ST_dbld fields equals
+ // parent's (unless alloc_xpt, when it should == 0).
if (alloc_xpt == xpt) {
- sk_assert(0 == xpt->spacetime2);
+ sk_assert(0 == xpt->exact_ST_dbld);
} else {
sum = 0;
for (i = 0; i < xpt->n_children; i++) {
- sum += xpt->children[i]->spacetime2;
+ sum += xpt->children[i]->exact_ST_dbld;
}
- //sk_assert(sum == xpt->spacetime2);
+ //sk_assert(sum == xpt->exact_ST_dbld);
// It's possible that not all the children were included in the
- // spacetime2 calculations. Hopefully almost all of them were, and
+ // exact_ST_dbld calculations. Hopefully almost all of them were, and
// all the important ones.
-// sk_assert(sum <= xpt->spacetime2);
-// sk_assert(sum * 1.05 > xpt->spacetime2 );
-// if (sum != xpt->spacetime2) {
-// VG_(printf)("%ld, %ld\n", sum, xpt->spacetime2);
+// sk_assert(sum <= xpt->exact_ST_dbld);
+// sk_assert(sum * 1.05 > xpt->exact_ST_dbld );
+// if (sum != xpt->exact_ST_dbld) {
+// VG_(printf)("%ld, %ld\n", sum, xpt->exact_ST_dbld);
// }
}
@@ -1592,6 +1607,6 @@ static void pp_all_XPts2(Int fd, Queue*
make_perc(heap_spacetime, total_spacetime), maybe_br);
} else {
- // Remember: spacetime2 is space.time *doubled*
- perc = make_perc(xpt->spacetime2 / 2, total_spacetime);
+ // Remember: exact_ST_dbld is space.time *doubled*
+ perc = make_perc(xpt->exact_ST_dbld / 2, total_spacetime);
if (is_HTML) {
SPRINTF(buf, "<a name=\"b%x\"></a>"
@@ -1607,7 +1622,7 @@ static void pp_all_XPts2(Int fd, Queue*
}
- // Sort children by spacetime2
+ // Sort children by exact_ST_dbld
VG_(ssort)(xpt->children, xpt->n_children, sizeof(XPt*),
- XPt_cmp_spacetime2);
+ XPt_cmp_exact_ST_dbld);
SPRINTF(buf, "%s\nCalled from:%s\n", maybe_p, maybe_ul);
@@ -1616,5 +1631,5 @@ static void pp_all_XPts2(Int fd, Queue*
// Stop when <1% of total spacetime
- if (child->spacetime2 * 1000 / (total_spacetime * 2) < 5) {
+ if (child->exact_ST_dbld * 1000 / (total_spacetime * 2) < 5) {
UInt n_insig = xpt->n_children - i;
Char* s = ( n_insig == 1 ? "" : "s" );
@@ -1626,6 +1641,6 @@ static void pp_all_XPts2(Int fd, Queue*
}
- // Remember: spacetime2 is space.time *doubled*
- perc = make_perc(child->spacetime2 / 2, total_spacetime);
+ // Remember: exact_ST_dbld is space.time *doubled*
+ perc = make_perc(child->exact_ST_dbld / 2, total_spacetime);
eip_desc = VG_(describe_eip)(child->eip-1, buf2, BUF_LEN);
if (is_HTML) {
@@ -1738,17 +1754,21 @@ print_summary(ULong total_ST, ULong heap
if (clo_heap)
VG_(message)(Vg_UserMsg, "heap: %s",
- make_perc(heap_ST, total_ST) );
+ ( 0 == total_ST ? (Char*)"(n/a)"
+ : make_perc(heap_ST, total_ST) ) );
// Heap admin --------------------------------------------------------
if (clo_heap_admin)
VG_(message)(Vg_UserMsg, "heap admin: %s",
- make_perc(heap_admin_ST, total_ST));
+ ( 0 == total_ST ? (Char*)"(n/a)"
+ : make_perc(heap_admin_ST, total_ST) ) );
sk_assert( VG_(HT_count_nodes)(malloc_list) == n_heap_blocks );
// Stack(s) ----------------------------------------------------------
- if (clo_stacks)
+ if (clo_stacks) {
+ sk_assert(0 != total_ST);
VG_(message)(Vg_UserMsg, "stack(s): %s",
- make_perc(stack_ST, total_ST));
+ make_perc(stack_ST, total_ST) );
+ }
if (VG_(clo_verbosity) > 1) {
@@ -1784,5 +1804,5 @@ void SK_(fini)(Int exit_status)
// Redo spacetimes of significant contexts to match the .hp file.
- calc_spacetime2(&heap_ST, &heap_admin_ST, &stack_ST);
+ calc_exact_ST_dbld(&heap_ST, &heap_admin_ST, &stack_ST);
total_ST = heap_ST + heap_admin_ST + stack_ST;
write_hp_file ( );
|
|
From: Tom H. <th...@cy...> - 2004-08-30 18:56:51
|
In message <200...@of...>
Julian Seward <js...@ac...> wrote:
> +86407 Add partial support for the low-level parallel port driver ioctls.
I believe this is actually complete as I filled in the blanks when
committing it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-30 18:55:19
|
In message <Pin...@bl...>
Bob Friesenhahn <bfr...@si...> wrote:
> On Mon, 30 Aug 2004, Julian Seward wrote:
>
> >
> > Ok, folks, this is the final call for 2.2.0. I've updated NEWS,
> > hopefully appropriately. Let me know if there's anything else
> > to go in. Nick, I'm assuming you'll commit your fix for #78765.
> > I'll update docs, version numbers, etc, later this evening.
>
> If the timer_* support code is ok, it would be cool if it made it into
> the release.
If people are happy for it to go in - it's only some system call
wrapper so can't break much - then I'll commit it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob F. <bfr...@si...> - 2004-08-30 18:26:24
|
On Mon, 30 Aug 2004, Julian Seward wrote: > > Ok, folks, this is the final call for 2.2.0. I've updated NEWS, > hopefully appropriately. Let me know if there's anything else > to go in. Nick, I'm assuming you'll commit your fix for #78765. > I'll update docs, version numbers, etc, later this evening. If the timer_* support code is ok, it would be cool if it made it into the release. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Julian S. <js...@ac...> - 2004-08-30 18:22:39
|
Ok, folks, this is the final call for 2.2.0. I've updated NEWS, hopefully appropriately. Let me know if there's anything else to go in. Nick, I'm assuming you'll commit your fix for #78765. I'll update docs, version numbers, etc, later this evening. If tonight's autobuilds don't show any unusual breakage, I'll tag the tree tomorrow morning, and run with that. J |
|
From: Julian S. <js...@ac...> - 2004-08-30 18:15:46
|
CVS commit by jseward: Try to summarise 2.0.0 -> 2.2.0 changes. M +36 -0 NEWS 1.25 --- valgrind/NEWS #1.24:1.25 @@ -2,4 +2,40 @@ Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2.2.0 brings nine months worth of improvements and bug fixes. We +believe it to be a worthy successor to 2.0.0. There are literally +hundreds of bug fixes and minor improvements. There are also some +fairly major user-visible changes: + +* A complete overhaul of handling of system calls and signals, and + their interaction with threads. In general, the accuracy of the + system call, thread and signal simulations is much improved: + + - Blocking system calls behave exactly as they do when running + natively (not on valgrind). That is, if a syscall blocks only the + calling thread when running natively, than it behaves the same on + valgrind. No more mysterious hangs because V doesn't know that some + syscall or other, should block only the calling thread. + + - Interrupted syscalls should now give more faithful results. + + - Signal contexts in signal handlers are supported. + +* Improvements to NPTL support to the extent that V now works + properly on NPTL-only setups. + +* Greater isolation between Valgrind and the program being run, so + the program is less likely to inadvertently kill Valgrind by + doing wild writes. + +* Massif: a new space profiling tool. Try it! It's cool, and it'll + tell you in detail where and when your C/C++ code is allocating heap. + Draws pretty .ps pictures of memory use against time. A potentially + powerful tool for making sense of your program's space use. + +* File descriptor leakage checks. When enabled, Valgrind will print out + a list of open file descriptors on exit. + +* Improved SSE2/SSE3 support. + |
|
From: Julian S. <js...@ac...> - 2004-08-30 18:04:51
|
CVS commit by jseward: Document 2.1.2 -> 2.2.0 deltas (2.0.0 -> 2.2.0 not yet done) M +84 -0 NEWS 1.24 --- valgrind/NEWS #1.23:1.24 @@ -1,3 +1,87 @@ +Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.1.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2.2.0 is not much different from 2.1.2, released seven weeks ago. +A number of bugs have been fixed, most notably #85658, which gave +problems for quite a few people. There have been many internal +cleanups, but those are not user visible. + +The following bugs have been fixed since 2.1.2: + +85658 Assert in coregrind/vg_libpthread.c:2326 (open64) != + (void*)0 failed + This bug was reported multiple times, and so the following + duplicates of it are also fixed: 87620, 85796, 85935, 86065, + 86919, 86988, 87917, 88156 + +80716 Semaphore mapping bug caused by unmap (sem_destroy) + (Was fixed prior to 2.1.2) + +86987 semctl and shmctl syscalls family is not handled properly + +86696 valgrind 2.1.2 + RH AS2.1 + librt + +86730 valgrind locks up at end of run with assertion failure + in __pthread_unwind + +86641 memcheck doesn't work with Mesa OpenGL/ATI on Suse 9.1 + (also fixes 74298, a duplicate of this) + +85947 MMX/SSE unhandled instruction 'sfence' + +84978 Wrong error "Conditional jump or move depends on + uninitialised value" resulting from "sbbl %reg, %reg" + +86254 ssort() fails when signed int return type from comparison is + too small to handle result of unsigned int subtraction + +87089 memalign( 4, xxx) makes valgrind assert + +86407 Add partial support for the low-level parallel port driver ioctls. + +70587 Add timestamps to Valgrind output? (wishlist) + +84937 vg_libpthread.c:2505 (se_remap): Assertion `res == 0' + (fixed prior to 2.1.2) + +86317 cannot load libSDL-1.2.so.0 using valgrind + +86989 memcpy from mac_replace_strmem.c complains about + uninitialized pointers passed when length to copy is zero + +85811 gnu pascal symbol causes segmentation fault; ok in 2.0.0 + +79138 writing to sbrk()'d memory causes segfault + +77369 sched deadlock while signal received during pthread_join + and the joined thread exited + +88115 In signal handler for SIGFPE, siginfo->si_addr is wrong + under Valgrind + +78765 Massif crashes on app exit if FP exceptions are enabled + +Additionally there are the following changes, which are not +connected to any bug report numbers, AFAICS: + +* Fix scary bug causing mis-identification of SSE stores vs + loads and so causing memcheck to sometimes give nonsense results + on SSE code. + +* Add support for the POSIX message queue system calls. + +* Fix to allow 32-bit Valgrind to run on AMD64 boxes. Note: this does + NOT allow Valgrind to work with 64-bit executables - only with 32-bit + executables on an AMD64 box. + +* At configure time, only check whether linux/mii.h can be processed + so that we don't generate ugly warnings by trying to compile it. + + + Developer (cvs head) release 2.1.2 (18 July 2004) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
From: Tom H. <th...@cy...> - 2004-08-30 15:46:48
|
In message <Pin...@bl...>
Bob Friesenhahn <bfr...@si...> wrote:
> On Mon, 30 Aug 2004, Tom Hughes wrote:
>
> > They should all be sumple enough. The only signal related thing looked
> > like timer_create being able to ask for a signal to be delivered when
> > the timer expires and that doesn't need anything special.
>
> This patch provides an implementation. It may be complete crap, but
> then again, maybe it will hasten development.
There were a couple of mistakes in timer_create but it was mostly
correct by the looks of it. Attached is my tidied up version to
which I have added most of the clock_ routines as well - all except
clock_nanosleep in fact as that requires more work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob F. <bfr...@si...> - 2004-08-30 15:13:46
|
On Mon, 30 Aug 2004, Tom Hughes wrote:
> In message <413...@bi...>
> Sebastian Biallas <sb...@bi...> wrote:
>
>> I'm about to implement the following syscall wrappers for valgrind:
>>
>> timer_create
>> timer_delete
>> timer_settime
>> clock_getres
>>
>> But before I'd like to ask:
>>
>> a) Is there already an implementation/patch/development version somewhere?
>
> I thought some of them had been done, but I can't find any sign of it...
>
>> b) Is this feasable without stepping to deep into valgrind (since some
>> of the above functions seem to need signal-handling special cases)?
>
> They should all be sumple enough. The only signal related thing looked
> like timer_create being able to ask for a signal to be delivered when
> the timer expires and that doesn't need anything special.
This patch provides an implementation. It may be complete crap, but
then again, maybe it will hasten development.
Bob
Index: coregrind/vg_syscalls.c
===================================================================
RCS file: /home/kde/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.97
diff -u -r1.97 vg_syscalls.c
--- coregrind/vg_syscalls.c 13 Jun 2004 14:23:00 -0000 1.97
+++ coregrind/vg_syscalls.c 30 Aug 2004 15:09:57 -0000
@@ -1,3 +1,4 @@
+#define SUPPORT_TIMERS 1 /* ReQuest added timer_ support */
/*--------------------------------------------------------------------*/
/*--- Handle system calls. vg_syscalls.c ---*/
@@ -4952,6 +4953,76 @@
VG_TRACK(post_mem_write, arg1, sizeof(struct timex));
}
+#if SUPPORT_TIMERS
+PRE(timer_create)
+{
+ /*
+ int timer_create(clockid_t clock_id, struct sigevent *evp, timer_t *timerid);
+ */
+ MAYBE_PRINTF("timer_create(%d,%p,%p)\n",arg1,arg2,arg3);
+ SYSCALL_TRACK( pre_mem_read, tid, "timer_create(evp)",arg2, sizeof(struct sigevent));
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_create(timerid)",arg3, sizeof(timer_t *));
+}
+
+POST(timer_create)
+{
+ VG_TRACK( post_mem_write, arg3, sizeof(timer_t *) );
+}
+
+PRE(timer_settime)
+{
+ /*
+ int timer_settime(timer_t timerid, int flags, const struct
+ itimerspec *value, struct itimerspec *ovalue);
+ */
+ MAYBE_PRINTF("timer_settime(%p,%d,%p,%p)\n",arg1,arg2,arg3,arg4);
+ SYSCALL_TRACK( pre_mem_read, tid, "timer_settime(value)", arg3,sizeof(struct vki_itimerspec));
+ if (arg4 != (UInt) NULL)
+ {
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_settime(ovalue)",arg4,sizeof(struct vki_itimerspec));
+ }
+}
+
+POST(timer_settime)
+{
+ if (arg4 != (UInt) NULL)
+ {
+ VG_TRACK( post_mem_write, arg4, sizeof(struct vki_itimerspec));
+ }
+}
+
+PRE(timer_gettime)
+{
+ /*
+ int timer_gettime(timer_t timerid, struct itimerspec *value);
+ */
+ MAYBE_PRINTF("timer_gettime(%p,%p)\n",arg1,arg2);
+ SYSCALL_TRACK( pre_mem_write, tid, "timer_gettime(value)",arg2,sizeof(struct vki_itimerspec));
+}
+
+POST(timer_gettime)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct vki_itimerspec));
+}
+
+PRE(timer_getoverrun)
+{
+ /*
+ int timer_getoverrun(timer_t timerid);
+ */
+ MAYBE_PRINTF("timer_getoverrun(%p)\n",arg1);
+}
+
+PRE(timer_delete)
+{
+ /*
+ int timer_delete(timer_t timerid);
+ */
+ MAYBE_PRINTF("timer_delete(%p)\n",arg1);
+}
+
+#endif /* SUPPORT_TIMERS */
+
PRE(clock_gettime)
{
/* int clock_gettime(clockid_t clk_id, struct timespec *tp); */
@@ -5415,6 +5486,13 @@
SYSB_(prctl, True),
SYSBA(adjtimex, False),
SYSBA(mmap2, False),
+#if SUPPORT_TIMERS
+ SYSBA(timer_create, False),
+ SYSBA(timer_settime, False),
+ SYSBA(timer_gettime, False),
+ SYSB_(timer_getoverrun, False),
+ SYSB_(timer_delete, False),
+#endif /* SUPPORT_TIMERS */
SYSBA(clock_gettime, False),
SYSBA(futex, True),
SYSB_(acct, False),
Index: include/vg_kerneliface.h
===================================================================
RCS file: /home/kde/valgrind/include/vg_kerneliface.h,v
retrieving revision 1.17
diff -u -r1.17 vg_kerneliface.h
--- include/vg_kerneliface.h 3 Jun 2004 10:00:42 -0000 1.17
+++ include/vg_kerneliface.h 30 Aug 2004 15:09:57 -0000
@@ -537,8 +537,6 @@
/* suseconds_t */ long tv_usec; /* microseconds */
};
-
-
/* For fcntl on fds ..
from ./include/asm-i386/fcntl.h */
#define VKI_F_DUPFD 0 /* dup */
@@ -559,6 +557,12 @@
long tv_nsec; /* nanoseconds */
};
+/* POSIX.1b structure for timer start values and intervals. */
+struct vki_itimerspec
+ {
+ struct vki_timespec it_interval;
+ struct vki_timespec it_value;
+ };
/* STAT stuff
from /usr/src/linux-2.4.9-31/include/asm-i386/stat.h */
|
|
From: Bob F. <bfr...@si...> - 2004-08-30 15:06:40
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: > Hi! > > I'm about to implement the following syscall wrappers for valgrind: > > timer_create > timer_delete > timer_settime > clock_getres > > But before I'd like to ask: > > a) Is there already an implementation/patch/development version somewhere? I have written wrappers for the timer_* functions but I didn't read kernel/glibc internals source code in order to do so. Therefore, my implementation may be useless. Due to this uncertainty, I have not submitted a patch. Regardless, a patched valgrind does seem to work ok (no reported error or crash) with programs using the timer_* functions. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Tom H. <th...@cy...> - 2004-08-30 15:00:49
|
In message <413...@bi...>
Sebastian Biallas <sb...@bi...> wrote:
> I'm about to implement the following syscall wrappers for valgrind:
>
> timer_create
> timer_delete
> timer_settime
> clock_getres
>
> But before I'd like to ask:
>
> a) Is there already an implementation/patch/development version somewhere?
I thought some of them had been done, but I can't find any sign of it...
> b) Is this feasable without stepping to deep into valgrind (since some
> of the above functions seem to need signal-handling special cases)?
They should all be sumple enough. The only signal related thing looked
like timer_create being able to ask for a signal to be delivered when
the timer expires and that doesn't need anything special.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 14:53:42
|
Hi! I'm about to implement the following syscall wrappers for valgrind: timer_create timer_delete timer_settime clock_getres But before I'd like to ask: a) Is there already an implementation/patch/development version somewhere? b) Is this feasable without stepping to deep into valgrind (since some of the above functions seem to need signal-handling special cases)? Sebastian |
|
From: Julian S. <js...@ac...> - 2004-08-30 11:32:11
|
> On Sunday 22 August 2004 01:51, Jeremy Fitzhardinge wrote: > [...] > GNU make is much better documented and more tractable than the teetering > pile of M4, perl, sh and Makefiles, and the reliance on their > overlapping syntax. > > So, I'd happily drop both automake and autoconf and do something more > kernel-like. Yes, I find the complexity of the current build system scary and a potential (actual?) maintenance problem. And so I'd also be inclined to dump automake/autoconf in a hole* if possible, and do something simpler. Or at least dump automake? Is it viable/useful to back off to just autoconf? > On Sunday 22 August 2004 02:11, Bob Friesenhahn wrote: > Comparing GNU make to Automake is almost like comparing an assembly > language with a compiled language. =C2=A0It is easy enough to get started > with GNU make for small programs, but building serious projects with > the expected bells and whistles takes considerable effort just to get > the framework in place. Bob, can you show some specifics of what we would be losing by moving to a GNU-make-only system? Currently I have no clear idea of what the tradeoff is. J * providing of course this didn't cause environmental damage. Are they biodegradable? |
|
From: Tom H. <th...@cy...> - 2004-08-30 11:21:17
|
In message <01b801c48e82$967ec6c0$0207a8c0@avocado>
"Chris January" <ch...@at...> wrote:
> > You added a stopped flag to the thread state, and you test it
> > in several places but you never seem to set it to anything?
> >
> > The reason I noticed that was that I was trying to see if
> > there was some reason for adding that flag rather than a new
> > VgTs_Stopped state that would indicate the same thing.
>
> The stopped flag (like the single_step flag) would be set by the debugger.
> The reason it's a seperate flag and not a new VgTs_Stopped state is that
> when the debugger stops a thread it may be in any state (not just
> VgTs_Runnable). When the debugger resumes the thread it needs to restore the
> state to its previous value. The easiest way to do this is not to modify the
> state at all and have separate flag.
Ah right. I thought the idea was that it would be set when a breakpoint
was hit but it's more general that.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|