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
(26) |
2
(35) |
3
(18) |
4
(14) |
|
5
(12) |
6
(13) |
7
(11) |
8
(15) |
9
(8) |
10
(13) |
11
(25) |
|
12
(13) |
13
(24) |
14
(7) |
15
(6) |
16
(8) |
17
(6) |
18
(7) |
|
19
(8) |
20
(7) |
21
(5) |
22
(7) |
23
(6) |
24
(7) |
25
(6) |
|
26
(7) |
27
(7) |
28
(5) |
29
(5) |
30
(5) |
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 15:54:01
|
On Fri, 3 Sep 2004, Paul Mackerras wrote: > One fix is to change ratio to a double. But it seems to me that the > second floating-point computation is unnecessary. Is there any good > reason why we don't just set VG_(shadow_end) = VG_(valgrind_base) and > work out shadow_size from that? The patch below does that, and fixes > the user's problem. > > Paul. > > diff -urN valgrind-2.2.0-ppc/coregrind/vg_main.c valgrind-pie/coregrind/vg_main.c > --- valgrind-2.2.0-ppc/coregrind/vg_main.c 2004-08-31 08:02:50.000000000 +1000 > +++ valgrind-pie/coregrind/vg_main.c 2004-09-02 23:14:12.648769024 +1000 > @@ -439,9 +439,9 @@ > /* where !FIXED mmap goes */ > VG_(client_mapbase) = PGROUNDDN((addr_t)(client_size * CLIENT_HEAP_PROPORTION)); > > - shadow_size = PGROUNDUP(client_size * ratio); > VG_(shadow_base) = VG_(client_end) + REDZONE_SIZE; > - VG_(shadow_end) = VG_(shadow_base) + shadow_size; > + VG_(shadow_end) = VG_(valgrind_base); > + shadow_size = VG_(valgrind_base) - VG_(shadow_base); Committed, thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 15:53:41
|
CVS commit by nethercote:
Simplify calculation of VG_(shadow_end) to avoid an obscure bug on Paul M's PPC
port caused by rounding errors.
M +4 -5 vg_main.c 1.202
M +2 -1 x86/core_arch.h 1.3
--- valgrind/coregrind/vg_main.c #1.201:1.202
@@ -454,7 +454,7 @@ static void layout_remaining_space(Addr
PGROUNDDN((addr_t)(client_size * CLIENT_HEAP_PROPORTION));
- shadow_size = PGROUNDUP(client_size * ratio);
VG_(shadow_base) = VG_(client_end) + REDZONE_SIZE;
- VG_(shadow_end) = VG_(shadow_base) + shadow_size;
+ VG_(shadow_end) = VG_(valgrind_base);
+ shadow_size = VG_(shadow_end) - VG_(shadow_base);
#define SEGSIZE(a,b) ((VG_(b) - VG_(a))/(1024*1024))
@@ -466,5 +466,5 @@ static void layout_remaining_space(Addr
"client_end %8x (%dMB)\n"
"shadow_base %8x (%dMB)\n"
- "shadow_end %8x (%dMB)\n"
+ "shadow_end %8x\n"
"valgrind_base %8x (%dMB)\n"
"valgrind_end %8x\n",
@@ -473,5 +473,5 @@ static void layout_remaining_space(Addr
VG_(client_end), SEGSIZE(client_end, shadow_base),
VG_(shadow_base), SEGSIZE(shadow_base, shadow_end),
- VG_(shadow_end), SEGSIZE(shadow_end, valgrind_base),
+ VG_(shadow_end),
VG_(valgrind_base), SEGSIZE(valgrind_base, valgrind_end),
VG_(valgrind_end)
@@ -2717,5 +2717,4 @@ void VG_(sanity_check_general) ( Bool fo
| (may be 0 sized) |
shadow_end +-------------------------+
- : gap (may be 0 sized) :
valgrind_base +-------------------------+
| kickstart executable |
--- valgrind/coregrind/x86/core_arch.h #1.2:1.3
@@ -89,5 +89,6 @@ typedef struct _LDT_ENTRY {
// Architecture-specific part of a ThreadState
// XXX: eventually this should be made abstract, ie. the fields not visible
-// to the core...
+// to the core... then VgLdtEntry can be made non-visible to the core
+// also.
typedef struct {
/* Pointer to this thread's Local (Segment) Descriptor Table.
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 15:38:17
|
On Sat, 4 Sep 2004, Chris January wrote: > The end result of these changes is to make it easy to add debugging support > at a later stage because support for breakpoints and single stepping is > already in the Valgrind core. No further changes would (hopefully) be > required. I'd rather see the whole proposed change working before committing pieces of it. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 15:28:49
|
CVS commit by nethercote:
Arch-abstraction: introduce constants for min and max instruction sizes.
M +2 -3 cachegrind/cg_main.c 1.78
M +2 -1 coregrind/vg_errcontext.c 1.61
M +2 -1 coregrind/vg_symtab2.c 1.88
M +4 -1 include/x86/tool_arch.h 1.2
--- valgrind/cachegrind/cg_main.c #1.77:1.78
@@ -46,5 +46,4 @@ typedef struct {
/*------------------------------------------------------------*/
-#define MAX_x86_INSTR_SIZE 16 // According to ia32 sw dev manual vol 2
#define MIN_LINE_SIZE 16
#define FILE_LEN 256
@@ -432,6 +431,6 @@ void end_of_x86_instr(UCodeBlock* cb, in
t_data_addr2 = INVALID_TEMPREG;
- sk_assert(instr_size >= 1 &&
- instr_size <= MAX_x86_INSTR_SIZE);
+ sk_assert(instr_size >= MIN_INSTR_SIZE &&
+ instr_size <= MAX_INSTR_SIZE);
#define IS_(X) (INVALID_TEMPREG != t_##X##_addr)
--- valgrind/coregrind/vg_errcontext.c #1.60:1.61
@@ -362,5 +362,6 @@ static void gen_suppression(Error* err)
do {
Addr eip = ec->eips[i];
- if (i > 0) eip--; /* point to calling line */
+ if (i > 0)
+ eip -= MIN_INSTR_SIZE; // point to calling line
if ( VG_(get_fnname_nodemangle) (eip, buf, M_VG_ERRTXT) ) {
// Stop after "main"; if main() is recursive, stop after last main().
--- valgrind/coregrind/vg_symtab2.c #1.87:1.88
@@ -2227,5 +2227,6 @@ void VG_(mini_stack_dump) ( Addr eips[],
do {
Addr eip = eips[i];
- if (i > 0) eip--; /* point to calling line */
+ if (i > 0)
+ eip -= MIN_INSTR_SIZE; // point to calling line
VG_(describe_eip)(eip, buf, M_VG_ERRTXT);
--- valgrind/include/x86/tool_arch.h #1.1:1.2
@@ -38,4 +38,7 @@
#define N_ARCH_REGS 8
+#define MIN_INSTR_SIZE 1
+#define MAX_INSTR_SIZE 16
+
#endif // __X86_TOOL_ARCH_H
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 12:52:02
|
On Sat, 4 Sep 2004, Eric Estievenart wrote: > I thought that when using memcheck or addrcheck, Valgrind already > tested memory access and didn't need extra hardware protection. Memcheck/Addrcheck warn about a bad writes that could trash Valgrind's data, but don't prevent them. And other tools also deserve protection. So another mechanism is needed, and currently that mechanism is the segment selectors. Yes, they are x86-specific; hence the discussion about masking pointers as an alternative approach. > Honestly, I don't believe we can smoothly have V or the client > taking the best of the memory without sharing some areas of > the address space, or requiring the user to manually setup > V layout for each (or many) program, through obscure cmdline > arguments, which would be confusing... I believe my proposal strikes a good balance between protecting Valgrind from buggy clients while also efficiently using the address space. The protection isn't architecture-neutral, but it would be a clear improvement on what we currently have. N |
|
From: Chris J. <ch...@at...> - 2004-09-04 10:51:38
|
> > > Now that 2.2.0 is out is there any chance of getting the > first of my > > > debugging support patches into CVS? > > > > Should I treat the silence as an implicit 'no'? > > Not necessarily. What you should take it as is there are a > bunch of other large-scale structural changes to the software > which we're dealing with right now, so thinking about your > patch in detail is going to be delayed by that. Your best > bet is to shout again in a month or so, and see what happens then. My apologies. I did not wish to sound impatient. Different projects have different policies for patches, etc. It's hard to know what the correct procedure is. Chris January |
|
From: Chris J. <ch...@at...> - 2004-09-04 10:50:11
|
> On Fri, 3 Sep 2004, Chris January wrote: >=20 > >> Now that 2.2.0 is out is there any chance of getting the=20 > first of my=20 > >> debugging support patches into CVS? > > > > Should I treat the silence as an implicit 'no'? >=20 > No. More likely that no-one has any strong opinions, or are=20 > busy with=20 > other things at the moment. >=20 >=20 > I looked at your patch, but haven't run it. I'm confused by a few=20 > things. >=20 >=20 > - The single_step field you added to ThreadState -- it=20 > doesn't seem ever=20 > be set. No - neither single_step or stopped are set anywhere at present. This = patch provides the infrastructure for adding debugging support but since there = is no debugger or debugger stub in Valgrind yet the two variables will = never get set. >=20 >=20 > - You've changed a few test conditions by one, and changed=20 > the 'jz' in the=20 > dispatch loop to 'jle', but have not explained why this is necessary.=20 > Some comments in the code would be helpful. I changed the tests for VG_(dispatch_ctr) so that setting it to 1 will execute only a single basic block. Previously setting it to 1 would = execute no basic blocks at all. >=20 >=20 > - You added 'stopped' to ThreadState, but I also can't see=20 > how it is set. As above the variable isn't set anywhere yet since no debugging stub = exists. >=20 >=20 > - 'stopped' is used like this: >=20 > + if (VG_(threads)[tid_next].status =3D=3D VgTs_Runnable = && > + !VG_(threads)[tid_next].stopped) >=20 > should 'stopped' rather be folded into the 'status' type=20 > somehow? Eg.=20 > have a VgTs_RunnableButStopped state, or similar? See my earlier reply to Tom Hughes. "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." >=20 >=20 > - You said: >=20 > > These should be the only changes to existing parts of > > the core that are required to support live debugging. Obviously this > > patch doesn't add full debugging support in and of itself. >=20 > What more is required to get full debugging support? How=20 > much code will=20 > it be? This depends on how it is implemented. If debugging support is = implemented using the method used here: http://www.atomice.com/gdb-valgrind.html = then the very little extra code is required. However that patch requires modifications to GDB. An (IMHO better) alternative is to implement a GDB server/stub in Valgrind which would require no or trivial changes to = GDB. Gdbserver could be used a starting point for this - it's about 20/25 = files. >=20 >=20 > - This code is unnecessarily repetitive: >=20 > + if (trc =3D=3D VG_TRC_EBP_JMP_BREAKPOINT) { > + /* A software breakpoint. */ > + vg_tid_currently_in_baseBlock =3D = vg_tid_last_in_baseBlock; > + VG_(kkill) (0, VKI_SIGTRAP); > + vg_tid_currently_in_baseBlock =3D 0; > + break; > + } > + > + if (trc =3D=3D VG_TRC_INNER_COUNTERZERO && > + VG_(threads)[tid].single_step) { > + vg_tid_currently_in_baseBlock =3D = vg_tid_last_in_baseBlock; > + VG_(kkill) (0, VKI_SIGTRAP); > + vg_tid_currently_in_baseBlock =3D 0; > + break; > + } Granted - the original patch had different code in the if blocks. >=20 >=20 > Finally, I still don't understand what the end result is=20 > intended to be=20 > with these proposed changes -- do you start GDB, then load=20 > your program=20 > under a Valgrind tool, then run it? Or something else? The end result of these changes is to make it easy to add debugging = support at a later stage because support for breakpoints and single stepping is already in the Valgrind core. No further changes would (hopefully) be required. Chris January |
|
From: Tom H. <th...@cy...> - 2004-09-04 03:14:41
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-09-04 02:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow int: valgrind ./int map_unmap: valgrind ./map_unmap mq: valgrind ./mq mremap: valgrind ./mremap munmap_exe: valgrind ./munmap_exe pth_blockedsig: valgrind ./pth_blockedsig pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts Could not read `shorts.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-09-04 02:55:29
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-09-04 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-09-04 02:26:24
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-09-04 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-04 02:19:28
|
Nightly build on audi ( Red Hat 9 ) started at 2004-09-04 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 9 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_cancel2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-04 02:13:27
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-09-04 03:10:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-04 02:08:24
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-09-04 03:05:04 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |
|
From: Eric E. <eri...@fr...> - 2004-09-04 01:35:32
|
Nicholas Nethercote wrote: > Originally we didn't use big-bang. Jeremy put it in with the FV memory > layout changes; AIUI he experimented with direct-offset shadow > addressing but the performance was no better, so the committed version > didn't use it, even though the code to support it was all present. I now understand why I didn't understand it at first ;-) Sorry to have had you re-explain that just for me, I read too quickly a previous mail explaining it. >> - No more address address space separation between >> Valgrind and client > > This is unacceptable. > It is needed. The separation between client and Valgrind is important, > and was one of the main motivations for the FV rearrangement in the > first place -- by using a segment selector in client code, we can ensure > that a buggy client cannot touch any of Valgrind's memory. Sorry (again), I was not aware of the --pointer-check option (huh, not in the doc ?;-) and the protection through the ldt when running simd code. I thought that when using memcheck or addrcheck, Valgrind already tested memory access and didn't need extra hardware protection. (Maybe there are some issues if the client gives strange args to some syscall, but we should detect that.) But even if there is no point running a buggy program (which generally segfaults) under other tools before having fixed them, it is clear that preventing the client to mess up with V structures is good. Honestly, I don't believe we can smoothly have V or the client taking the best of the memory without sharing some areas of the address space, or requiring the user to manually setup V layout for each (or many) program, through obscure cmdline arguments, which would be confusing... We clearly don't need a "barrier", but just plain memory protection, when switching between simd / V code. The barrier is a solution to achieve that protection on x86, using selectors, which is efficient (but awfully intel-dependant). However I don't have any other solution for now. Have a rest, I'll take a break so I won't bother you for a week ;-) Hopefully I'll have fresh ideas by then, but we are touching highly hardware dependant stuff with which I'm not very at ease :-P Cheers -- Eric |