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
(31) |
2
(27) |
|
3
(25) |
4
(21) |
5
(21) |
6
(21) |
7
(32) |
8
(23) |
9
(15) |
|
10
(12) |
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(7) |
16
(20) |
|
17
(14) |
18
(71) |
19
(67) |
20
(50) |
21
(25) |
22
(15) |
23
(37) |
|
24
(25) |
25
(41) |
26
(34) |
27
(57) |
28
(20) |
29
(30) |
30
(13) |
|
31
(18) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 22:12:19
|
On Wed, 20 Jul 2005, Julian Seward wrote: >> On solaris I'm getting the following error when >> running an app using valgrind. > > Uh, did I miss something? You're running the 3.X line on > Solaris x86 ? (: Naveen's the one who's been working on a Solaris port. Sounds like he's making some progress... N |
|
From: Julian S. <js...@ac...> - 2005-07-20 22:03:31
|
> On solaris I'm getting the following error when > running an app using valgrind. Uh, did I miss something? You're running the 3.X line on Solaris x86 ? > vex x86->IR: unhandled instruction bytes: 0xF8 0x2A > 0x7 0x8B > > The code that triggered this was > f8 clc > 2a 07 subb (%edi),%al > 8b fa movl %edx,%edi > > I looked at the vex code priv/guest-x86/toIR.c and the > case for 0xF8 (CLC) seems to be commented out. Is > there a reason for this ? Yes -- that code is from the old UCode JIT. Flag handling in x86 vex is completely different. I'll look into it. J |
|
From: Dirk M. <mu...@kd...> - 2005-07-20 21:49:03
|
SVN commit 437078 by mueller:
Handle a 'd' stab that indicates a file in pascal.
Backport from SVN-3.0 -r4220 and Fixes #89914
M +3 -2 vg_stabs.c =20
--- trunk/valgrind/coregrind/vg_stabs.c #437077:437078
@@ -727,8 +727,9 @@
}
=20
case 'k': /* const */
- case 'B': { /* volatile */
- /* ('k' | 'B') TYPE */
+ case 'B': /* volatile */
+ case 'd': { /* file (pascal only) */
+ /* ('k' | 'B' | 'd' ) TYPE */
type =3D stabtype_parser(si, NULL, &p);
break;
}
|
|
From: Naveen K. <g_n...@ya...> - 2005-07-20 21:48:36
|
Hi all,
On solaris I'm getting the following error when
running an app using valgrind.
vex x86->IR: unhandled instruction bytes: 0xF8 0x2A
0x7 0x8B
The code that triggered this was
f8 clc
2a 07 subb (%edi),%al
8b fa movl %edx,%edi
I looked at the vex code priv/guest-x86/toIR.c and the
case for 0xF8 (CLC) seems to be commented out. Is
there a reason for this ? Is this a simple fix where I
can uncomment the lines out and tweak the statements
or is there something else ?
Thanks
Naveen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Dirk M. <mu...@kd...> - 2005-07-20 21:45:30
|
SVN commit 437076 by mueller:
fix stabs reading for freepascal, backport of SVN-3.0 -r4218
M +1 -0 vg_stabs.c =20
--- trunk/valgrind/coregrind/vg_stabs.c #437075:437076
@@ -646,6 +646,7 @@
case -27: type =3D VG_(st_mkint)(def, 1, True); break;
case -28: type =3D VG_(st_mkint)(def, 2, True); break;
case -29: type =3D VG_(st_mkint)(def, 4, True); break;
+ case -30: type =3D ML_(st_mkint)(def, 2, False); break;
case -31: type =3D VG_(st_mkint)(def, 8, True); break;
case -32: type =3D VG_(st_mkint)(def, 8, False); break;
case -33: type =3D VG_(st_mkint)(def, 8, False); break;
|
|
From: <sv...@va...> - 2005-07-20 17:48:22
|
Author: tom
Date: 2005-07-20 18:48:18 +0100 (Wed, 20 Jul 2005)
New Revision: 4220
Log:
Handle a 'd' stab that indicates a file in pascal. Fixes bug #89914.
Modified:
trunk/coregrind/m_debuginfo/stabs.c
Modified: trunk/coregrind/m_debuginfo/stabs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_debuginfo/stabs.c 2005-07-20 16:05:28 UTC (rev 4219=
)
+++ trunk/coregrind/m_debuginfo/stabs.c 2005-07-20 17:48:18 UTC (rev 4220=
)
@@ -735,8 +735,9 @@
}
=20
case 'k': /* const */
- case 'B': { /* volatile */
- /* ('k' | 'B') TYPE */
+ case 'B': /* volatile */
+ case 'd': { /* file (pascal only) */
+ /* ('k' | 'B' | 'd') TYPE */
type =3D stabtype_parser(si, NULL, &p);
break;
}
|
|
From: <sv...@va...> - 2005-07-20 16:06:39
|
Author: tom
Date: 2005-07-20 17:05:28 +0100 (Wed, 20 Jul 2005)
New Revision: 4219
Log:
Make VG_(kill_self) use kill to send the signal, not tkill, as we are
sending it to the whole process not a single thread.
This routine is only used when we absolutely want to terminate
valgrind and as things stand it fails if called from anything other
than the initial thread as it winds up sending the signal to the main
thread only and that typically doesn't even exist any more so we
fall through and panic.
Modified:
trunk/coregrind/m_signals.c
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2005-07-20 13:56:22 UTC (rev 4218)
+++ trunk/coregrind/m_signals.c 2005-07-20 16:05:28 UTC (rev 4219)
@@ -899,7 +899,7 @@
VG_(sigaddset)(&mask, sigNo);
VG_(sigprocmask)(VKI_SIG_UNBLOCK, &mask, &origmask);
=20
- VG_(tkill)(VG_(getpid)(), sigNo);
+ VG_(kill)(VG_(getpid)(), sigNo);
=20
VG_(sigaction)(sigNo, &origsa, NULL);
VG_(sigprocmask)(VKI_SIG_SETMASK, &origmask, NULL);
|
|
From: Qin Z.
|
Quoting Raphael Zulliger <zu...@iz...>: > hi! > > I googled around, but couldn't find any related posts... > > Has someone ever though about a windows port of valgrind? I don't say > that I would start doing it, but I'm at least interested in doing such a > project together with my colleague... > Imagine we would now start studying the valgrind source, is there a > chance to port valgrind to windows at all? what are the problems? It > would help, if you could list all problematic things that you can > imagine of. Mojo and DynamoRIO are two tools that works in windows, but neither of them are open-source. You may want to have a look at their work to have an idea of the problems. Mojo: http://www.cs.washington.edu/homes/lerns/mojo.pdf DynamoRIO: http://www.cag.lcs.mit.edu/dynamorio/ > > Or the other question: Is anyone already porting it to windows and could > need some help? If yes, what kind of help (no, we don't like to document > things ;-)) > > thanks, Raphael > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 15:15:39
|
On Wed, 20 Jul 2005, Raphael Zulliger wrote: > Has someone ever though about a windows port of valgrind? I don't say that I > would start doing it, but I'm at least interested in doing such a project > together with my colleague... > Imagine we would now start studying the valgrind source, is there a chance to > port valgrind to windows at all? what are the problems? It would help, if you > could list all problematic things that you can imagine of. > > Or the other question: Is anyone already porting it to windows and could need > some help? If yes, what kind of help (no, we don't like to document things > ;-)) Someone named KJK::Hyperion discussed this in some depth on the valgrind-developers list in late February/early March last year in a thread called "Developing Valgrind for Windows". The short answer is: it would be *very* difficult, as Valgrind has many UNIX assumptions. To make it work at all, I believe large parts of Valgrind would have to be rewritten, enough to almost warrant a separate project. N |
|
From: Raphael Z. <zu...@iz...> - 2005-07-20 15:08:50
|
hi! I googled around, but couldn't find any related posts... Has someone ever though about a windows port of valgrind? I don't say that I would start doing it, but I'm at least interested in doing such a project together with my colleague... Imagine we would now start studying the valgrind source, is there a chance to port valgrind to windows at all? what are the problems? It would help, if you could list all problematic things that you can imagine of. Or the other question: Is anyone already porting it to windows and could need some help? If yes, what kind of help (no, we don't like to document things ;-)) thanks, Raphael |
|
From: <sv...@va...> - 2005-07-20 14:23:21
|
Author: njn
Date: 2005-07-20 15:23:13 +0100 (Wed, 20 Jul 2005)
New Revision: 142
Log:
tweak
Modified:
trunk/gallery/survey_current/survey.html
Modified: trunk/gallery/survey_current/survey.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/gallery/survey_current/survey.html 2005-07-19 22:05:03 UTC (rev=
141)
+++ trunk/gallery/survey_current/survey.html 2005-07-20 14:23:13 UTC (rev=
142)
@@ -51,7 +51,8 @@
value=3D"q3. What hardware do you use Valgrind on"/>
<b>3. </b>What hardware do you use Valgrind on?<br />
Estimate the proportion of your Valgrind usage on different
- machines. (Example: Pentium 4 70%, Athlon 30%)<br />
+ machines. (Example: Pentium 4 70%, Athlon64 (32-bit mode) 20%,
+ Athlon64 (64-bit mode) 10%)<br />
<textarea name=3D"Q3[txt]" rows=3D"2" cols=3D"56"></textarea>
</td></tr>
<tr><td>
|
|
From: <sv...@va...> - 2005-07-20 13:56:24
|
Author: tom
Date: 2005-07-20 14:56:22 +0100 (Wed, 20 Jul 2005)
New Revision: 4218
Log:
Handle stabs builtin type -30 (wide characters, 16 bit unsigned).
Modified:
trunk/coregrind/m_debuginfo/stabs.c
Modified: trunk/coregrind/m_debuginfo/stabs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_debuginfo/stabs.c 2005-07-20 13:49:55 UTC (rev 4217=
)
+++ trunk/coregrind/m_debuginfo/stabs.c 2005-07-20 13:56:22 UTC (rev 4218=
)
@@ -654,6 +654,7 @@
case -27: type =3D ML_(st_mkint)(def, 1, True); break;
case -28: type =3D ML_(st_mkint)(def, 2, True); break;
case -29: type =3D ML_(st_mkint)(def, 4, True); break;
+ case -30: type =3D ML_(st_mkint)(def, 2, False); break;
case -31: type =3D ML_(st_mkint)(def, 8, True); break;
case -32: type =3D ML_(st_mkint)(def, 8, False); break;
case -33: type =3D ML_(st_mkint)(def, 8, False); break;
|
|
From: <sv...@va...> - 2005-07-20 13:50:00
|
Author: tom
Date: 2005-07-20 14:49:55 +0100 (Wed, 20 Jul 2005)
New Revision: 4217
Log:
Document different argument order for clone on amd64.
Modified:
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-20 13:45:43 U=
TC (rev 4216)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-20 13:49:55 U=
TC (rev 4217)
@@ -496,7 +496,9 @@
VG_(sigprocmask)(VKI_SIG_SETMASK, &mask, &fork_saved_mask);
=20
/* Since this is the fork() form of clone, we don't need all that
- VG_(clone) stuff */
+ VG_(clone) stuff - note that the last two arguments are the
+ opposite way round to x86 and ppc32 as the amd64 kernel expects
+ the arguments in a different order */
res =3D VG_(do_syscall5)( __NR_clone, flags,=20
(UWord)NULL, (UWord)parent_tidptr,=20
(UWord)child_tidptr, (UWord)NULL );
|
|
From: <sv...@va...> - 2005-07-20 13:45:50
|
Author: tom
Date: 2005-07-20 14:45:43 +0100 (Wed, 20 Jul 2005)
New Revision: 4216
Log:
Bring the vki_sigevent_t definition into line with current kernels.
Modified:
trunk/include/vki-linux.h
Modified: trunk/include/vki-linux.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/vki-linux.h 2005-07-20 13:18:23 UTC (rev 4215)
+++ trunk/include/vki-linux.h 2005-07-20 13:45:43 UTC (rev 4216)
@@ -440,13 +440,17 @@
#define VKI_SI_USER 0 /* sent by kill, sigsend, raise */
#define VKI_SI_TKILL -6 /* sent by tkill system call */
=20
-#define VKI_SIGEV_MAX_SIZE 64
-#ifndef VKI_SIGEV_PAD_SIZE
-#define VKI_SIGEV_PAD_SIZE ((VKI_SIGEV_MAX_SIZE/sizeof(int)) - 3)
+/*
+ * This works because the alignment is ok on all current architectures
+ * but we leave open this being overridden in the future
+ */
+#ifndef VKI___ARCH_SIGEV_PREAMBLE_SIZE
+#define VKI___ARCH_SIGEV_PREAMBLE_SIZE (sizeof(int) * 2 + sizeof(vki_sig=
val_t))
#endif
=20
-// [[Nb: in 2.6.8.1, this constant is never defined...]]
-#ifndef HAVE_ARCH_SIGEVENT_T
+#define VKI_SIGEV_MAX_SIZE 64
+#define VKI_SIGEV_PAD_SIZE ((VKI_SIGEV_MAX_SIZE - VKI___ARCH_SIGEV_PREAM=
BLE_SIZE) \
+ / sizeof(int))
=20
typedef struct vki_sigevent {
vki_sigval_t sigev_value;
@@ -463,8 +467,6 @@
} _sigev_un;
} vki_sigevent_t;
=20
-#endif
-
//----------------------------------------------------------------------
// From elsewhere...
//----------------------------------------------------------------------
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 13:42:45
|
On Wed, 20 Jul 2005, Tom Hughes wrote: >> Well spotted; but (mystified) the implication is that the amd64 >> arg order for __NR_clone is different from what it is on x86 ? >> Is that right? > > Yes - I checked the kernel source for both. I nearly changed the x86 > one as well but then I check the kernel source and realised it was > actually the comment in that assembly code that was wrong for x86. > > I think on x86 they are in the order they were added in but for amd64 > they took the opportunity to order them more logically. Did you add a comment in the AMD64 code explaining the different order to x86? N |
|
From: <sv...@va...> - 2005-07-20 13:18:27
|
Author: njn Date: 2005-07-20 14:18:23 +0100 (Wed, 20 Jul 2005) New Revision: 4215 Log: Move config.h inclusion from pub_tool_basics.h to pub_core_basics.h so it= 's not seen by external tools. This was requested by Josef W. Modified: trunk/coregrind/pub_core_basics.h trunk/include/pub_tool_basics.h Modified: trunk/coregrind/pub_core_basics.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/coregrind/pub_core_basics.h 2005-07-20 09:32:35 UTC (rev 4214) +++ trunk/coregrind/pub_core_basics.h 2005-07-20 13:18:23 UTC (rev 4215) @@ -58,8 +58,12 @@ # error Unknown arch #endif =20 +// For jmp_buf #include <setjmp.h> =20 +// Autoconf-generated settings +#include "config.h" + #endif // __PUB_CORE_BASICS_H =20 /*--------------------------------------------------------------------*/ Modified: trunk/include/pub_tool_basics.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/include/pub_tool_basics.h 2005-07-20 09:32:35 UTC (rev 4214) +++ trunk/include/pub_tool_basics.h 2005-07-20 13:18:23 UTC (rev 4215) @@ -52,9 +52,6 @@ // For varargs types #include <stdarg.h> =20 -// Autoconf-generated settings -#include "config.h" - // Kernel types. Might as well have them here, they're used so broadly // (eg. in pub_core_threadstate.h). #if defined(VGO_linux) |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 13:16:34
|
On Wed, 20 Jul 2005, Tom Hughes wrote: > You can specify a time as well: > > svn co svn://svn.valgrind.org/valgrind/trunk -r '{2005-07-19T07:11}' valgrind > > so this should do: > > svn co svn://svn.valgrind.org/valgrind/trunk \ > -r {`date --date=yesterday +%Y-%m-%dT%H:%M:%S`} \ > valgrind Aha! Thanks, Tom. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 13:11:12
|
On Wed, 20 Jul 2005, Josef Weidendorfer wrote: > What happens if you want to have a dual installation on an Opteron, i.e. both > Valgrind x86 and x86_64? This works now out of the box if you use different > install prefixes (and separate installations), but that is a strange > installation. > Some convention here seems to be to add a "64" at the end of directory/file > names. E.g. I could search for a valgrind64.pc file. > > Or should we leave this problem to distributors? I don't think we have a clear solution to this problem. > Sorry. The question was meant to ask if the header files installed have > anything specific to the architecture used for compilation, or if they are > common to all supported architectures. There are some arch-specific files, namely the vki*.h ones, and some of the others have #ifdefs that depend on the architecture (eg. pub_tool_basics.h). Is this a problem? > As vex is obviously part of valgrinds tool API, but vex is a library on its > own now: can external tools assume that valgrinds tool API version is > incremented whenever there is an change in vex's API? Yes. > Thinking loud: a config.h file only has system info needed for compilation of > the current package (i.e valgrind). A dependent package (callgrind) should do > its own configure checks needed for its compilation. > I suppose you should include the config.h directly in *.c files where a given > configure check is needed (or package name/version defines). I'm wary of including only in the places where it is needed. This is because a lot of the time if you forget to include it in one of these places, you might not get an obvious error -- ie. some constant won't be defined that should be defined, and it will silently cause misbehaviour. I think I'll just include it in pub_core_basics.h rather than pub_tool_basics.h; that's basically how it used to be (ie. we included it in core.h rather than tool.h). N |
|
From: <sv...@va...> - 2005-07-20 10:55:33
|
Author: sewardj
Date: 2005-07-20 11:55:26 +0100 (Wed, 20 Jul 2005)
New Revision: 1283
Log:
Implement SBB Ev,Gv.
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-07-20 10:15:34 UTC (rev 1282)
+++ trunk/priv/guest-amd64/toIR.c 2005-07-20 10:55:26 UTC (rev 1283)
@@ -2436,7 +2436,6 @@
putIRegG(size, pfx, rm, mkexpr(dst1));
} else
if (addSubCarry && op8 =3D=3D Iop_Sub8) {
- vassert(0); /* awaiting test case */
helper_SBB( size, dst1, dst0, src );
putIRegG(size, pfx, rm, mkexpr(dst1));
} else {
@@ -11868,9 +11867,9 @@
//.. //-- case 0x1A: /* SBB Eb,Gb */
//.. //-- delta =3D dis_op2_E_G ( sorb, True, SBB, True, 1, delta,=
"sbb" );
//.. //-- break;
-//.. case 0x1B: /* SBB Ev,Gv */
-//.. delta =3D dis_op2_E_G ( sorb, True, Iop_Sub8, True, sz, delta=
, "sbb" );
-//.. break;
+ case 0x1B: /* SBB Ev,Gv */
+ delta =3D dis_op2_E_G ( pfx, True, Iop_Sub8, True, sz, delta, "sbb=
" );
+ break;
=20
case 0x22: /* AND Eb,Gb */
if (haveF2orF3(pfx)) goto decode_failure;
|
|
From: <sv...@va...> - 2005-07-20 10:15:41
|
Author: sewardj
Date: 2005-07-20 11:15:34 +0100 (Wed, 20 Jul 2005)
New Revision: 1282
Log:
Implement LOOP disp8 (0xE2).
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-07-20 09:23:13 UTC (rev 1281)
+++ trunk/priv/guest-amd64/toIR.c 2005-07-20 10:15:34 UTC (rev 1282)
@@ -619,9 +619,13 @@
static Bool haveF3 ( Prefix pfx ) {
return toBool((pfx & PFX_F3) > 0);
}
+
static Bool have66 ( Prefix pfx ) {
return toBool((pfx & PFX_66) > 0);
}
+static Bool haveASO ( Prefix pfx ) {
+ return toBool((pfx & PFX_ASO) > 0);
+}
=20
/* Return True iff pfx has 66 set and F2 and F3 clear */
static Bool have66noF2noF3 ( Prefix pfx )
@@ -11523,11 +11527,28 @@
//..=20
//.. //-- case 0xE0: /* LOOPNE disp8 */
//.. //-- case 0xE1: /* LOOPE disp8 */
-//.. //-- case 0xE2: /* LOOP disp8 */
-//.. //-- /* Again, the docs say this uses ECX/CX as a count depen=
ding on
-//.. //-- the address size override, not the operand one. Sinc=
e we
-//.. //-- don't handle address size overrides, I guess that mea=
ns
-//.. //-- ECX. */
+ case 0xE2: /* LOOP disp8 */
+ /* The docs say this uses RCX/ECX as a count depending on
+ the address size override, not the operand one. Since we
+ don't handle address size overrides, I guess that means
+ RCX. */
+ if (!haveF3(pfx) && !haveF2(pfx) && !have66(pfx) && !haveASO(pfx))=
{
+ /* RCX--; if (RCX !=3D 0) goto d64; */
+ d64 =3D guest_RIP_curr_instr + getSDisp8(delta) + 2; delta++;
+ DIP("loop 0x%llx\n", (ULong)d64);
+ putIReg64(R_RCX, binop(Iop_Sub64, getIReg64(R_RCX), mkU64(1)) )=
;
+ stmt( IRStmt_Exit(=20
+ binop(Iop_CmpNE64,getIReg64(R_RCX),mkU64(0)),=20
+ Ijk_Boring,=20
+ IRConst_U64(d64)=20
+ ));
+ dres.whatNext =3D Dis_StopHere;
+ irbb->next =3D mkU64(guest_RIP_curr_instr + 2);
+ irbb->jumpkind =3D Ijk_Boring;
+ break;
+ }
+ goto decode_failure;
+
//.. //-- d32 =3D (eip+1) + getSDisp8(eip); eip++;
//.. //-- t1 =3D newTemp(cb);
//.. //-- uInstr2(cb, GET, 4, ArchReg, R_ECX, TempReg, t1);
|
|
From: <sv...@va...> - 2005-07-20 09:32:41
|
Author: tom
Date: 2005-07-20 10:32:35 +0100 (Wed, 20 Jul 2005)
New Revision: 4214
Log:
The timeout argument to rt_sigtimedwait is in the third argument not
the fourth, plus linux allows it to be null.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-20 09:24:04 UTC (=
rev 4213)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-20 09:32:35 UTC (=
rev 4214)
@@ -5243,8 +5243,9 @@
PRE_MEM_READ( "rt_sigtimedwait(set)", ARG1, sizeof(vki_sigset_t)=
);
if (ARG2 !=3D 0)
PRE_MEM_WRITE( "rt_sigtimedwait(info)", ARG2, sizeof(vki_siginfo_t=
) );
- PRE_MEM_READ( "rt_sigtimedwait(timeout)",
- ARG4, sizeof(struct vki_timespec) );
+ if (ARG3 !=3D 0)
+ PRE_MEM_READ( "rt_sigtimedwait(timeout)",
+ ARG3, sizeof(struct vki_timespec) );
}
=20
POST(sys_rt_sigtimedwait)
|
|
From: <sv...@va...> - 2005-07-20 09:24:08
|
Author: tom
Date: 2005-07-20 10:24:04 +0100 (Wed, 20 Jul 2005)
New Revision: 4213
Log:
More system call fixups.
Modified:
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_syswrap/syswrap-x86-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-20 08:46:50 U=
TC (rev 4212)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-20 09:24:04 U=
TC (rev 4213)
@@ -1307,7 +1307,7 @@
GENX_(__NR_chroot, sys_chroot), // 161=20
GENX_(__NR_sync, sys_sync), // 162=20
// (__NR_acct, sys_acct), // 163=20
- // (__NR_settimeofday, sys_settimeofday), // 164=20
+ GENX_(__NR_settimeofday, sys_settimeofday), // 164=20
=20
LINX_(__NR_mount, sys_mount), // 165
// (__NR_umount2, sys_umount), // 166=20
@@ -1377,17 +1377,17 @@
=20
PLAX_(__NR_semtimedop, sys_semtimedop), // 220=20
LINX_(__NR_fadvise64, sys_fadvise64), // 221=20
- // (__NR_timer_create, sys_timer_create), // 222=20
- // (__NR_timer_settime, sys_timer_settime), // 223=20
- // (__NR_timer_gettime, sys_timer_gettime), // 224=20
+ GENXY(__NR_timer_create, sys_timer_create), // 222=20
+ GENXY(__NR_timer_settime, sys_timer_settime), // 223=20
+ GENXY(__NR_timer_gettime, sys_timer_gettime), // 224=20
=20
- // (__NR_timer_getoverrun, sys_timer_getoverrun)// 225=20
- // (__NR_timer_delete, sys_timer_delete), // 226=20
- // (__NR_clock_settime, sys_clock_settime), // 227=20
+ GENX_(__NR_timer_getoverrun, sys_timer_getoverrun), // 225=20
+ GENX_(__NR_timer_delete, sys_timer_delete), // 226=20
+ GENX_(__NR_clock_settime, sys_clock_settime), // 227=20
GENXY(__NR_clock_gettime, sys_clock_gettime), // 228=20
- // (__NR_clock_getres, sys_clock_getres), // 229=20
+ GENXY(__NR_clock_getres, sys_clock_getres), // 229=20
=20
- // (__NR_clock_nanosleep, sys_clock_nanosleep),// 230=20
+ GENXY(__NR_clock_nanosleep, sys_clock_nanosleep),// 230=20
LINX_(__NR_exit_group, sys_exit_group), // 231=20
LINXY(__NR_epoll_wait, sys_epoll_wait), // 232=20
LINX_(__NR_epoll_ctl, sys_epoll_ctl), // 233=20
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-20 08:46:50 UTC (=
rev 4212)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-20 09:24:04 UTC (=
rev 4213)
@@ -5646,6 +5646,23 @@
POST_MEM_WRITE( ARG2, sizeof(struct vki_timespec) );
}
=20
+PRE(sys_clock_nanosleep)
+{
+ *flags |=3D SfMayBlock|SfPostOnFail;
+ PRINT("sys_clock_nanosleep( %d, %d, %p, %p )", ARG1,ARG2,ARG3,ARG4);
+ PRE_REG_READ4(int32_t, "clock_nanosleep",
+ vki_clockid_t, clkid, int, flags,
+ const struct timespec *, rqtp, struct timespec *, rmtp)=
;
+ PRE_MEM_READ( "clock_nanosleep(rqtp)", ARG3, sizeof(struct vki_timesp=
ec) );
+ if (ARG4 !=3D 0)
+ PRE_MEM_WRITE( "clock_nanosleep(rmtp)", ARG4, sizeof(struct vki_ti=
mespec) );
+}
+POST(sys_clock_nanosleep)
+{
+ if (ARG4 !=3D 0 && FAILURE && RES_unchecked =3D=3D VKI_EINTR)
+ POST_MEM_WRITE( ARG4, sizeof(struct vki_timespec) );
+}
+
#undef PRE
#undef POST
=20
Modified: trunk/coregrind/m_syswrap/syswrap-x86-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-x86-linux.c 2005-07-20 08:46:50 UTC=
(rev 4212)
+++ trunk/coregrind/m_syswrap/syswrap-x86-linux.c 2005-07-20 09:24:04 UTC=
(rev 4213)
@@ -2263,7 +2263,7 @@
=20
GENXY(__NR_clock_gettime, sys_clock_gettime), // (timer_create+6=
)
GENXY(__NR_clock_getres, sys_clock_getres), // (timer_create+7=
)
-//zz // (__NR_clock_nanosleep, sys_clock_nanosleep),// (timer_cre=
ate+8) */*
+ GENXY(__NR_clock_nanosleep, sys_clock_nanosleep),// (timer_create+8=
) */*
GENXY(__NR_statfs64, sys_statfs64), // 268
GENXY(__NR_fstatfs64, sys_fstatfs64), // 269
=20
|
|
From: <sv...@va...> - 2005-07-20 09:23:25
|
Author: sewardj
Date: 2005-07-20 10:23:13 +0100 (Wed, 20 Jul 2005)
New Revision: 1281
Log:
Implement F3 90 (rep nop).
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-07-20 01:12:48 UTC (rev 1280)
+++ trunk/priv/guest-amd64/toIR.c 2005-07-20 09:23:13 UTC (rev 1281)
@@ -619,6 +619,9 @@
static Bool haveF3 ( Prefix pfx ) {
return toBool((pfx & PFX_F3) > 0);
}
+static Bool have66 ( Prefix pfx ) {
+ return toBool((pfx & PFX_66) > 0);
+}
=20
/* Return True iff pfx has 66 set and F2 and F3 clear */
static Bool have66noF2noF3 ( Prefix pfx )
@@ -12430,66 +12433,7 @@
}
goto decode_failure;
=20
-//.. case 0xA5:=20
-//.. dis_string_op( dis_MOVS, ( opc =3D=3D 0xA4 ? 1 : sz ), "movs"=
, sorb );
-//.. break;
=20
-//.. case 0xA4: /* MOVS, no REP prefix */
-//.. case 0xA5:=20
-//.. dis_string_op( dis_MOVS, ( opc =3D=3D 0xA4 ? 1 : sz ), "movs"=
, sorb );
-//.. break;
-
-//.. case 0xF3: {=20
-//.. Addr32 eip_orig =3D guest_eip_bbstart + delta - 1;
-//.. vassert(sorb =3D=3D 0);
-//.. abyte =3D getUChar(delta); delta++;
-//..=20
-//.. if (abyte =3D=3D 0x66) { sz =3D 2; abyte =3D getUChar(delta);=
delta++; }
-//.. whatNext =3D Dis_StopHere;
-//..=20
-//.. switch (abyte) {
-//.. case 0xA4: sz =3D 1; /* REP MOVS<sz> */
-//.. case 0xA5:
-//.. dis_REP_op ( X86CondAlways, dis_MOVS, sz, eip_orig,=20
-//.. guest_eip_bbstart+delta, "rep =
movs" );
-//.. break;
-//..=20
-//.. case 0xA6: sz =3D 1; /* REPE CMP<sz> */
-//.. case 0xA7:
-//.. dis_REP_op ( X86CondZ, dis_CMPS, sz, eip_orig,=20
-//.. guest_eip_bbstart+delta, "repe cmps=
" );
-//.. break;
-//..=20
-//.. case 0xAA: sz =3D 1; /* REP STOS<sz> */
-//.. case 0xAB:
-//.. dis_REP_op ( X86CondAlways, dis_STOS, sz, eip_orig,=20
-//.. guest_eip_bbstart+delta, "rep =
stos" );
-//.. break;
-//.. //--=20
-//.. //-- case 0xAE: sz =3D 1; /* REPE SCAS<sz> */
-//.. //-- case 0xAF:=20
-//.. //-- dis_REP_op ( cb, CondZ, dis_SCAS, sz, eip_orig, eip, =
"repe scas" );
-//.. //-- break;
-//.. =20
-//.. case 0x90: /* REP NOP (PAUSE) */
-//.. /* a hint to the P4 re spin-wait loop */
-//.. DIP("rep nop (P4 pause)\n");
-//.. jmp_lit(Ijk_Yield, ((Addr32)guest_eip_bbstart)+delta);
-//.. whatNext =3D Dis_StopHere;
-//.. break;
-//..=20
-//.. //-- case 0xC3: /* REP RET */
-//.. //-- /* AMD K7/K8-specific optimisation; faster than vanil=
la RET */
-//.. //-- dis_ret(cb, 0);
-//.. //-- DIP("rep ret\n");
-//.. //-- break;
-//..=20
-//.. default:
-//.. goto decode_failure;
-//.. }
-//.. break;
-//.. }
-
/* ------------------------ XCHG ----------------------- */
=20
case 0x86: /* XCHG Gb,Eb */
@@ -12522,6 +12466,15 @@
break;
=20
case 0x90: /* XCHG eAX,eAX */
+ /* detect and handle F3 90 (rep nop) specially */
+ if (!have66(pfx) && !haveF2(pfx) && haveF3(pfx)) {
+ DIP("rep nop (P4 pause)\n");
+ /* "observe" the hint. The Vex client needs to be careful not
+ to cause very long delays as a result, though. */
+ jmp_lit(Ijk_Yield, guest_RIP_bbstart+delta);
+ dres.whatNext =3D Dis_StopHere;
+ break;
+ }
/* detect and handle NOPs specially */
if (/* F2/F3 probably change meaning completely */
!haveF2orF3(pfx)
|
|
From: Tom H. <to...@co...> - 2005-07-20 08:49:20
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Wednesday 20 July 2005 04:41, sv...@va... wrote:
>> Author: njn
>> Date: 2005-07-20 03:41:31 +0100 (Wed, 20 Jul 2005)
>> New Revision: 4205
>>
>> Log:
>> Reinstate stack trace printing on assertion failures. It's terrible
>> for the module dependency graph, but it's very useful.
>
> I suppose this can be solved by using callbacks ("interface") without
> disturbing the module dependency graph: m_libcassert.c would signal via the
> interface that the action of "pp_sched_status" is needed at some point in
> time, but would not have the implementation, and thus no dependency.
> The user of m_libcassert can register the correct handler when it also uses
> m_stacktrace.
You don't even need to go that far - making all users of assert pass
a callback function is a bit nasty.
Better is to have a static callback function in m_libcassert and a
routine to register it - then when an assertion fires the callback is
called if there is one. During startup the callback can be registered
once the point has been reached where is it possible.
That way assertions get stack traces when possible and the loops in
the dependency graph are broken.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-07-20 08:47:26
|
Author: tom Date: 2005-07-20 09:46:37 +0100 (Wed, 20 Jul 2005) New Revision: 4211 Log: Update ignore list. Modified: trunk/docs/internals/ Property changes on: trunk/docs/internals ___________________________________________________________________ Name: svn:ignore + Makefile Makefile.in |