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
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Jeremy F. <je...@go...> - 2004-01-23 23:09:35
|
CVS commit by fitzhardinge:
Fix bug 73219. This adds a general mechanism for querying the host CPU's
capabilities, and uses it to see if it has SSE/SSE2/fxsave support before
trying to use fxsave at startup.
M +35 -0 coregrind/vg_include.h 1.171
M +8 -8 coregrind/vg_main.c 1.139
M +88 -0 coregrind/vg_to_ucode.c 1.125
M +2 -2 include/vg_skin.h.base 1.10
--- valgrind/coregrind/vg_include.h #1.170:1.171
@@ -1137,4 +1137,39 @@ extern Bool VG_(is_chained_jumpsite)
------------------------------------------------------------------ */
+#define VG_X86_FEAT_FPU (0*32 + 0)
+#define VG_X86_FEAT_VME (0*32 + 1)
+#define VG_X86_FEAT_DE (0*32 + 2)
+#define VG_X86_FEAT_PSE (0*32 + 3)
+#define VG_X86_FEAT_TSC (0*32 + 4)
+#define VG_X86_FEAT_MSR (0*32 + 5)
+#define VG_X86_FEAT_PAE (0*32 + 6)
+#define VG_X86_FEAT_MCE (0*32 + 7)
+#define VG_X86_FEAT_CX8 (0*32 + 8)
+#define VG_X86_FEAT_APIC (0*32 + 9)
+#define VG_X86_FEAT_SEP (0*32 + 11)
+#define VG_X86_FEAT_MTRR (0*32 + 12)
+#define VG_X86_FEAT_PGE (0*32 + 13)
+#define VG_X86_FEAT_MCA (0*32 + 14)
+#define VG_X86_FEAT_CMOV (0*32 + 15)
+#define VG_X86_FEAT_PAT (0*32 + 16)
+#define VG_X86_FEAT_PSE36 (0*32 + 17)
+#define VG_X86_FEAT_CLFSH (0*32 + 19)
+#define VG_X86_FEAT_DS (0*32 + 21)
+#define VG_X86_FEAT_ACPI (0*32 + 22)
+#define VG_X86_FEAT_MMX (0*32 + 23)
+#define VG_X86_FEAT_FXSR (0*32 + 24)
+#define VG_X86_FEAT_SSE (0*32 + 25)
+#define VG_X86_FEAT_SSE2 (0*32 + 26)
+#define VG_X86_FEAT_SS (0*32 + 27)
+#define VG_X86_FEAT_HT (0*32 + 28)
+#define VG_X86_FEAT_TM (0*32 + 29)
+#define VG_X86_FEAT_PBE (0*32 + 31)
+
+#define VG_X86_FEAT_EST (1*32 + 7)
+#define VG_X86_FEAT_TM2 (1*32 + 8)
+#define VG_X86_FEAT_CNXTID (1*32 + 10)
+
+Bool VG_(cpu_has_feature)(UInt feat);
+
extern Int VG_(disBB) ( UCodeBlock* cb, Addr eip0 );
--- valgrind/coregrind/vg_main.c #1.138:1.139
@@ -503,12 +503,7 @@ Int VG_(exitcode) = 0;
Bool VG_(logging_to_filedes) = True;
-/* Is this a SSE/SSE2-capable CPU? If so, we had better save/restore
- the SSE state all over the place. This is set up very early, in
- vg_startup.S. We have to determine it early since we can't even
- correctly snapshot the startup machine state without it. */
-/* Initially True. Safer to err on the side of SSEness and get SIGILL
- than to not notice for some reason that we have SSE and get weird
- errors later on. */
-Bool VG_(have_ssestate) = True;
+/* This is set early to inidicate whether this CPU has the
+ SSE/fxsave/fxrestor features. */
+Bool VG_(have_ssestate);
@@ -1395,4 +1390,9 @@ void VG_(main) ( const KickstartParams *
VG_(m_state_static)[60/4] = kp->client_eip;
+ /* I assume that if we have SSE2 we also have SSE */
+ VG_(have_ssestate) =
+ VG_(cpu_has_feature)(VG_X86_FEAT_FXSR) &&
+ VG_(cpu_has_feature)(VG_X86_FEAT_SSE);
+
/* set up an initial FPU state (doesn't really matter what it is,
so long as it's somewhat valid) */
--- valgrind/coregrind/vg_to_ucode.c #1.124:1.125
@@ -41,4 +41,92 @@
/*------------------------------------------------------------*/
+/*--- CPU feature set stuff ---*/
+/*--- This is a little out of place here, but it will do ---*/
+/*--- for now. ---*/
+/*------------------------------------------------------------*/
+
+#define VG_N_FEATURE_WORDS 2
+
+static Int cpuid_level = -2; /* -2 -> not initialized */
+static UInt cpu_features[VG_N_FEATURE_WORDS];
+
+/* Standard macro to see if a specific flag is changeable */
+static inline Bool flag_is_changeable(UInt flag)
+{
+ UInt f1, f2;
+
+ asm("pushfl\n\t"
+ "pushfl\n\t"
+ "popl %0\n\t"
+ "movl %0,%1\n\t"
+ "xorl %2,%0\n\t"
+ "pushl %0\n\t"
+ "popfl\n\t"
+ "pushfl\n\t"
+ "popl %0\n\t"
+ "popfl\n\t"
+ : "=&r" (f1), "=&r" (f2)
+ : "ir" (flag));
+
+ return ((f1^f2) & flag) != 0;
+}
+
+
+/* Probe for the CPUID instruction */
+static Bool has_cpuid(void)
+{
+ return flag_is_changeable(EFlagID);
+}
+
+static inline UInt cpuid_eax(UInt eax)
+{
+ asm("cpuid" : "=a" (eax) : "0" (eax) : "bx", "cx", "dx");
+ return eax;
+}
+
+static inline void cpuid(UInt eax,
+ UInt *eax_ret, UInt *ebx_ret, UInt *ecx_ret, UInt *edx_ret)
+{
+ UInt ebx, ecx, edx;
+
+ asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "0" (eax));
+
+ if (eax_ret)
+ *eax_ret = eax;
+ if (ebx_ret)
+ *ebx_ret = ebx;
+ if (ecx_ret)
+ *ecx_ret = ecx;
+ if (edx_ret)
+ *edx_ret = edx;
+}
+
+static void get_cpu_features(void)
+{
+ if (!has_cpuid()) {
+ cpuid_level = -1;
+ return;
+ }
+
+ cpuid_level = cpuid_eax(0);
+
+ if (cpuid_level >= 1)
+ cpuid(1, NULL, NULL, &cpu_features[1], &cpu_features[0]);
+}
+
+Bool VG_(cpu_has_feature)(UInt feature)
+{
+ UInt word = feature / 32;
+ UInt bit = feature % 32;
+
+ if (cpuid_level == -2)
+ get_cpu_features();
+
+ vg_assert(word >= 0 && word < VG_N_FEATURE_WORDS);
+
+ return !!(cpu_features[word] & (1 << bit));
+}
+
+/*------------------------------------------------------------*/
/*--- Here so it can be inlined everywhere. ---*/
/*------------------------------------------------------------*/
--- valgrind/include/vg_skin.h.base #1.9:1.10
@@ -1,4 +1,3 @@
-
-/*--------------------------------------------------------------------*/
+/*-*- c -*- ----------------------------------------------------------*/
/*--- The only header your skin will ever need to #include... ---*/
/*--- vg_skin.h ---*/
@@ -955,4 +954,5 @@
#define EFlagD (1 << 10) /* direction */
#define EFlagO (1 << 11) /* overflow */
+#define EFlagID (1 << 21) /* changable if CPUID exists */
/* Liveness of general purpose registers, useful for code generation.
|
|
From: Doug R. <df...@nl...> - 2004-01-23 22:29:15
|
On Fri, 2004-01-23 at 21:34, Jeremy Fitzhardinge wrote: > On Fri, 2004-01-23 at 10:28, Doug Rabson wrote: > > Well if you are planning to drop this feature, it should tighten up the > > code generation for the low-overhead tools since you won't need the > > dec/test/branch at the beginning of each block, I guess. > > No, that code is there for thread context switching - the scheduler > switches to a new thread after N basic blocks (50000, I think). It's > use in --stop-after is secondary. I hadn't thought of that. Oh well - it seemed like a good idea at the time :-) |
|
From: Jeremy F. <je...@go...> - 2004-01-23 21:44:26
|
On Fri, 2004-01-23 at 10:17, Nicholas Nethercote wrote:
> Would it be possible to do it another way -- keep Valgrind running, but
> pass through the original code untouched? You could still put it in the
> translation table/cache, etc. Or does the code get fiddled enough by V to
> make this difficult?
Well, yes, that's what happens now, in a sense. --stop-after doesn't
make Valgrind evaporate, it just directly calls into the client code and
sets it going.
The trouble is that all the places in which V would normally interpose
itself will be unintercepted, so V can't do anything useful. This would
affect:
* stack growth - V normally catches SIGSEGV and grows the stack if
appropriate. We could leave a SIGSEGV handler in place to deal
with this, but if the client changes it, it loses
* signal syscalls - V normally does something special for all of
these, but they'll go straight to the kernel when running native
code
* threads - only the thread which happened to be running at
--stop-after will continue running; all the rest will be in
suspended animation
* client callbacks - anything the client was relying on client
callbacks for (most of libpthread, malloc, etc) will stop
working. Malloc is likely to be the most troublesome
So, if your client is single threaded, you aren't using a
malloc-intercepting tool, and the client doesn't want to grow its stack,
then it might be possible to keep running. With a fair amount of
engineering effort and complexity we can probably do better than this,
but it doesn't seem worth it.
J
|
|
From: Jeremy F. <je...@go...> - 2004-01-23 21:36:59
|
On Fri, 2004-01-23 at 10:28, Doug Rabson wrote: > Well if you are planning to drop this feature, it should tighten up the > code generation for the low-overhead tools since you won't need the > dec/test/branch at the beginning of each block, I guess. No, that code is there for thread context switching - the scheduler switches to a new thread after N basic blocks (50000, I think). It's use in --stop-after is secondary. J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 18:55:49
|
CVS commit by nethercote: Bugzilla not new anymore M +1 -2 bugs.html 1.8 M +1 -2 features.html 1.6 --- devel-home/valgrind/features.html #1.5:1.6 @@ -7,6 +7,5 @@ To request a feature, please use our <a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>; -make an entry with the severity "wishlist". Please note that this -Bugzilla page is new, and there may be some teething troubles. +make an entry with the severity "wishlist". <p> If you have trouble with Bugzilla, or for some reason you don't think --- devel-home/valgrind/bugs.html #1.7:1.8 @@ -13,6 +13,5 @@ If that fails, please file a report using our <a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>. -Patches for bugs are particularly welcome. Please note that this -Bugzilla page is new, and there may be some teething troubles. +Patches for bugs are particularly welcome. <p> If you have trouble with Bugzilla, or for some reason you don't think |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 18:39:09
|
On Fri, 23 Jan 2004, Doug Rabson wrote: > Well if you are planning to drop this feature, it should tighten up the > code generation for the low-overhead tools since you won't need the > dec/test/branch at the beginning of each block, I guess. Surely we could keep the feature, but only generate that testing code for each BB if somebody specifies --stop-after? Should be very easy to do. N |
|
From: Doug R. <df...@nl...> - 2004-01-23 18:29:24
|
On Fri, 2004-01-23 at 18:07, Jeremy Fitzhardinge wrote: > On Fri, 2004-01-23 at 09:20, Nicholas Nethercote wrote: > > Which is bad news for detecting bugs in the JIT-compiler; you can't do > > the binary search technique for finding erroneous BBs. > > > > (Well, you probably can if your error and the manifestation of it are > > close enough, but if it's a subtle error that doesn't manifest for a > > while, it won't work.) > > > > Any way we can achieve the same effect? > > Well, it was always a fairly crippled mechanism, since it never worked > with threaded programs, or if signals happened. > > I guess you could try to set up a limited environment which can coddle a > bit more execution out of the client, but it might turn out to be a > significant amount of work, which would be bad. And the more we do to > improve Valgrind's virtualization, the less likely it is that we can > maintain this easily. > > I agree with you about the debugging, but I don't really see how to > achieve it. Well if you are planning to drop this feature, it should tighten up the code generation for the low-overhead tools since you won't need the dec/test/branch at the beginning of each block, I guess. |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 18:17:14
|
On Fri, 23 Jan 2004, Jeremy Fitzhardinge wrote: > I guess you could try to set up a limited environment which can coddle a > bit more execution out of the client, but it might turn out to be a > significant amount of work, which would be bad. And the more we do to > improve Valgrind's virtualization, the less likely it is that we can > maintain this easily. Would it be possible to do it another way -- keep Valgrind running, but pass through the original code untouched? You could still put it in the translation table/cache, etc. Or does the code get fiddled enough by V to make this difficult? |
|
From: Jeremy F. <je...@go...> - 2004-01-23 18:07:16
|
On Fri, 2004-01-23 at 09:20, Nicholas Nethercote wrote: > Which is bad news for detecting bugs in the JIT-compiler; you can't do > the binary search technique for finding erroneous BBs. > > (Well, you probably can if your error and the manifestation of it are > close enough, but if it's a subtle error that doesn't manifest for a > while, it won't work.) > > Any way we can achieve the same effect? Well, it was always a fairly crippled mechanism, since it never worked with threaded programs, or if signals happened. I guess you could try to set up a limited environment which can coddle a bit more execution out of the client, but it might turn out to be a significant amount of work, which would be bad. And the more we do to improve Valgrind's virtualization, the less likely it is that we can maintain this easily. I agree with you about the debugging, but I don't really see how to achieve it. J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 17:20:34
|
On Fri, 23 Jan 2004, Jeremy Fitzhardinge wrote: > Yes, but I think --stop-after=NN is terminally wounded. I don't think > there's any way we can contrive to keep a working execution environment > for the client without Valgrind these days, since even things like > automatic stack growth are handled by V. Which is bad news for detecting bugs in the JIT-compiler; you can't do the binary search technique for finding erroneous BBs. (Well, you probably can if your error and the manifestation of it are close enough, but if it's a subtle error that doesn't manifest for a while, it won't work.) Any way we can achieve the same effect? N |
|
From: Jeremy F. <je...@go...> - 2004-01-23 17:03:03
|
On Fri, 2004-01-23 at 01:15, Doug Rabson wrote: > Isn't m_state_static also used to re-start the application when > switching back to the real cpu for --stop-after=NN? Right now this > doesn't work for me because it tries to load a set of null segment > registers. Yes, but I think --stop-after=NN is terminally wounded. I don't think there's any way we can contrive to keep a working execution environment for the client without Valgrind these days, since even things like automatic stack growth are handled by V. J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 16:30:43
|
Hi,
vg_dispatch.S has this code:
---------------------------
/* Set up the baseBlock pointer */
movl $VG_(baseBlock), %ebp
/* fetch m_eip into %eax */
movl VGOFF_(m_eip), %esi
movl (%ebp, %esi, 4), %eax
dispatch_main:
/* Jump here to do a new dispatch.
%eax holds destination (original) address.
%ebp indicates further details of the control transfer
requested to the address in %eax.
If ebp == & VG_(baseBlock), just jump next to %eax.
If ebp == VG_EBP_JMP_SYSCALL, do a system call before
continuing at eax.
If ebp == VG_EBP_JMP_CLIENTREQ, do a client request before
continuing at eax.
If %ebp has any other value, we panic.
*/
cmpl $VG_(baseBlock), %ebp
jnz dispatch_exceptional
/* fall into main loop */
dispatch_boring:
/* save the jump address at VG_(baseBlock)[VGOFF_(m_eip)] */
movl VGOFF_(m_eip), %esi
movl %eax, (%ebp, %esi, 4)
---------------------------
AFAICT, the entire bit between dispatch_main: and dispatch_boring: can be
removed -- the cmpl and the jnz never occur, because we've just loaded
%ebp with $VG_(baseBlock). I've tried it, it works fine. Maybe the
comment should be moved elsewhere, I'm not sure. I don't think it will
affect performance much, because it's outside the main loop, but still...
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 14:29:34
|
On Fri, 23 Jan 2004, Tom Hughes wrote: > > I've made quite a few more simplifications, and merged together various > > steps that were closely related; it's looking relatively clean, now. I > > would like someone else to confirm it works on their machine before I > > commit it. > > It seems largely OK to me. The main problem is that it doesn't compile > due to the VGP_PUSHCC(VgpStartup) and VGP_POPCC(VgpStartup) calls in > vg_main.c as VgpStartup doesn't seem to exist. Once I commented those > out it built and ran. Whoops, must edit vg_skin.h.base, not vg_skin.h. > The only other thing I noticed is that it is printing a message > whenever it sees a --tool:option=value type switch - did you mean > to leave that in or is it just some debugging? Just debugging, will remove. I'll update the patch on my website. Thanks. N |
|
From: Tom H. <th...@cy...> - 2004-01-23 14:23:15
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> I've updated the patch, it's at:
>
> www.cl.cam.ac.uk/~njn25/startup-merge.patch2
>
> I've made quite a few more simplifications, and merged together various
> steps that were closely related; it's looking relatively clean, now. I
> would like someone else to confirm it works on their machine before I
> commit it.
It seems largely OK to me. The main problem is that it doesn't compile
due to the VGP_PUSHCC(VgpStartup) and VGP_POPCC(VgpStartup) calls in
vg_main.c as VgpStartup doesn't seem to exist. Once I commented those
out it built and ran.
The only other thing I noticed is that it is printing a message
whenever it sees a --tool:option=value type switch - did you mean
to leave that in or is it just some debugging?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 13:02:28
|
On Wed, 21 Jan 2004, Jeremy Fitzhardinge wrote: > I think _VALGRIND_CLO should exclusively take precedence over all other > sources of command-line options (so if it is present, then 5 is > skipped). That's because it is constructed out of vg_argv, which in > turn is constructed out of all the sources when V first starts. Done. > > 8. set VG_(libdir) from VALGRINDLIB [after ??] ((move to after 3?)) > > Earlier is better. Done. > > 17. unpad shadow_end..0xffffffff [after 12] > > This should probably be shadow_end..valgrind_mmap_end; this will leave > the padding covering Valgrind's heap/stack, which will prevent unwanted > mappings from ending up there. This could be problematic (since the > stack won't be able to grow while the padding is there), so maybe the > answer is to make sure the Segment list has already blocked out > Valgrind's bss/heap/stack area for mapping, and just use VG_(mmap) for > address space allocation - see below at init_memory). I've left it unchanged for the moment. > m_state_static is a holdover from the old code, and isn't really > necessary anymore. It's just used to bootstrap the initial thread > state, but we could do it more directly. Partially removed; still needed for VG_(switch_to_real_cpu) as discussed elsewhere in this thread. > > 36. init_memory [after 23? (so we can parse proc/self/maps); complex, because > > it does several things] > > Maybe it should be split up. The most important thing it does is > initialize the Segment list. This point represents the boundary between > "mmap must be used, VG_(mmap) must not be used" and "VG_(mmap) must be > used, mmap must not be used". Since this is a subtle distinction, and > hard to police, I think it should happen as early as possible, and just > make everyone use VG_(mmap). > > This is a bit tricky, since ume.c/do_exec uses mmap(), but maybe we can > change it to use VG_(mmap), and give stage1 a stub definition of > VG_(mmap). If it uses VG_(mmap), it may also be able to encode more > information about the executable in the SF_* flags. I've inlined VG_(init_memory), but not moved the bits about, because I'm uncertain about the dependencies of all the mapping stuff. ---- I've updated the patch, it's at: www.cl.cam.ac.uk/~njn25/startup-merge.patch2 I've made quite a few more simplifications, and merged together various steps that were closely related; it's looking relatively clean, now. I would like someone else to confirm it works on their machine before I commit it. Jeremy, would you mind going through and looking at all the places I've marked with XXX? I had various question about things I didn't understand, and marked things that are broken, and where improvements could be made but I wasn't sure how best to do it. You could annotate my patch, or I could commit and then let you make more changes, whatever you prefer. N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-23 10:41:55
|
On Fri, 23 Jan 2004, Doug Rabson wrote: > Isn't m_state_static also used to re-start the application when > switching back to the real cpu for --stop-after=NN? Yes. I can remove the use of m_state_static use at startup -- working directly with the baseBlock instead -- but not when stopping like this. In principle I could use the baseBlock directly, but the baseBlock's layout is more complicated than m_state_static's, which makes it much harder to copy the values into the registers in vg_startup.S. It's easier to copy from the baseBlock into m_state_static, and then into the registers. > Right now this doesn't work for me because it tries to load a set of > null segment registers. I think it might be broken in general? Not sure. N |
|
From: Doug R. <df...@nl...> - 2004-01-23 09:16:11
|
On Thu, 2004-01-22 at 22:51, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-22 at 14:15, Nicholas Nethercote wrote: > > I can see how to constant-propagate things so it's not needed, but that > > raises an interesting question -- it seems most of the registers in > > baseBlock never get properly initialised as such. It seems %esp and %eip > > and the fp-state are initialised, but the rest of them are never set in > > m_state_static before it gets copied into the baseBlock; thus, they get > > set to zero (because m_state_static is a static struct and thus zeroed > > initially). > > > > I'm guessing that careful m_state_static setup was necessary pre-FV, when > > Valgrind got control some time after the program had started. But now it > > gets control before any meaningful values are put in the GP regs (except > > %esp), so their contents can be junk? > > More or less. I think the ABI says all the GP int registers are > meaningless except for edx, which Linux doesn't use and so zeros. > Obviously we need to set all the segment regs up into sane states, but > since we don't really use segments implicitly (we only pay attention to > explicit segment overrides, which are typically fs and gs), it doesn't > really matter. > > FP/MMX/SSE state also doesn't matter much, but we need to load it up > with something saneish. Isn't m_state_static also used to re-start the application when switching back to the real cpu for --stop-after=NN? Right now this doesn't work for me because it tries to load a set of null segment registers. |