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: Paul M. <pa...@sa...> - 2004-09-02 23:46:27
|
A user just hit a problem where stage2 would segfault very early when
using the addrcheck tool. He reported it to me because he was using
my PPC port, but in fact I think it is unrelated to PPC. It is
related to running with VG_(valgrind_base) = 0x70000000. We are
ending up with VG_(shadow_end) = 0x70001000, and we therefore lose the
mapping of the first page of stage2, and things go bad.
The problem is in layout_remaining_space. We set
client_size = ROUNDDN((VG_(valgrind_base)-REDZONE_SIZE) / (1.+ratio),
CLIENT_SIZE_MULTIPLE);
and then
shadow_size = PGROUNDUP(client_size * ratio);
and we have REDZONE_SIZE and CLIENT_SIZE_MULTIPLE both set to 1MB.
With addrcheck we have ratio = 0.125.
Now it turns out that 0x6ff is a multiple of 9, so
(VG_(valgrind_base) - REDZONE_SIZE) / (1. + ratio)
is a multiple of 1MB, in fact 0x63800000, and client_size * ratio is
0xc700000. Then when we do the PGROUNDUP, we end up with an
expression like
(Addr)((client_size * ratio) + (1 << 12) - 1)
This should give 0x70000fff. However, since ratio is declared as a
float, gcc does this computation in single-precision, which doesn't
have enough bits to represent this properly, and so it gets rounded to
0x70001000.
This doesn't happen with VG_(valgrind_base) = 0xb0000000, because
0xaff is not a multiple of 9, and thus the ROUNDDN reduces client_size
enough that the rounding error in calculating client_size * ratio +
4095 doesn't matter.
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);
#define SEGSIZE(a,b) ((VG_(b) - VG_(a))/(1024*1024))
|
|
From: Eric E. <eri...@fr...> - 2004-09-02 19:31:36
|
Nicholas Nethercote wrote:
>
> Shadow addressing is done with a two-level table. [...]
>
> So even though we have the conditions now for direct-offset shadow
> addressing (ie. we have a big contiguous block of shadow memory) we do
> *not* do direct-offset shadow addressing.
Well, I assumed that the big-bang alloc was made for the purpose
of direct offset shadow adressing, and so that it was done...
The question is then: What, at that time, decided you
to do the big-bang mmap ? I feel we may fall in a classic
software engineering syndrom, where you do one thing, change it
to another because it does not work well, change back to the first
because it is not better, then back to the second because you are
not satisfied, etc.
I have had a look at the ML archives, but couldn't find any
explication other than for direct offset shadow, and need for
a barrier between client and vg. But the reasons are not clear.
Any other hints on that ?
> Look at get_abit() and set_abit() in addrcheck/ac_main.c for examples.
Indeed, I had a look a few months ago, but did not remember the
particular details. It just means that we won't reduce performance
by... keeping the current implementation :-)
>>> Exactly, that's why I'm arguing against direct-offset shadow addressing.
Agreed, it's only trouble. The 32bit address space is too limited
to waste it. And the performance is correct with current scheme.
> Debug info reading is not the only problem. I listed 5 problems in my
> first email, debug info reading is only relevant to P5.
> this can easily exceed 256MB. This is the difference between P4 and P5
> in my first email. Go back and read them again.
Don't worry, I had them well in mind and in front of my eyes ;-)
I just need a few more tokens on P4, because we already
had possible supposedly working solutions for:
- P1: PIE + layout detection
- P2: PROT_NONE + MAP_NORESERVE and/or shm reservation
- P3: layout detection + (big bang or incremental shadow alloc)
Summarizing P4 and P5 gives the following constraints:
For P4, tools need to have a heap. They don't care where the big
areas are allocated, neither how they get chunked in small
blocks by VG_(malloc). Arenas improve perf, and that's good.
Flexible barrier (or no barrier) (would) help sharing the address
space between the tools and the client, because some times
the client requires a lot of mem, and some times the tools do.
P5: At any moment, we may need to have, say 500Mb of consecutive
address space available to map a big file. This is very temporary,
and while we have this mapping:
- The client does not execute
- We increase VG heap usage with the dbg infos we are parsing.
With the client needs being the following:
C1. text, data, bss fixed size segments
C2. a (down-growing) stack. May need to be very big in some cases
C3. an (up-growing) heap (brk) region. May need to be very big in some cases
C4. additional addressing space for file/anonymous mappings
(malloc will fallback to that if brk() fails
C5. reserved fixed address space ranges (very rarely)
And VG + tools needs being:
V1. text, data, bss - don't care where they are
V2. a small stack - idem
V3. chunks for shadow memory - not contiguous, don't care where they are
V4. mapping ranges for VG_(malloc) - no need to be contiguous
V5. Temporary BIG area for file mappings (for now)
I found a solution for P1..P5 which seems credible.
Based on the assumption that we don't need to have
a barrier (even flexible - BTW, what did you
mean by flexible ? command-line arg, or adjusting during
the execution ?), we can have C4, V3 and V4 interleaved,
and V5 taking the maximum space available after C3 and/or before
C2 since C2 and C3 won't grow while V5 (file mapping) is needed.
C2 (stack) should have a reasonable default, but be parametered
through a cmd-line arg (e.g. --min-stack-size) for
specific purposes.
Idem for C3 (brk). Note that having a limited heap region
should't bother too much apps, if their malloc uses
mmap() when brk() fails.
Optionally we could add --max-XXX-size if people want
to test under memory constraint.
So the following layout could work:
0 ===========================
Shared area 1 (DOWN)
...
VV--------------VV
available to vg & client
cli_data ===========================
client heap (DOWN)
...
cli_data_end VV----------------VV
[Temp vg mappings]
^^----------------^^
....
Shared area 2 (UP)
cli_stk_max ============================
Unused / Unusable
cli_stk_cur ^^----------------^^
.....
client stack, (UP)
space_end ============================
Kernel space
0xFFFFFFFF ============================
=== for limits fixed at once
--- for limits moving during the run
Shared areas (SAs) can contain C1, C4, V1, V3, V4
blocks.
Of course this is just an example, we may decide
to setup things differently, e.g.
- I didn't put the VG stack anywhere; could take
8 Mb in SA1, or be put at SA1 end, etc.
- Client stack is constrained, could be moved at
end of SA1 (needs arbitration between allocations
in SA1 and SA2 : less max client stack or less
maximum file mapping and less max client data.)
- There could be less or more shared areas
- Zones can be ordered in other manner
The important points in this idea are:
- No more address address space separation between
Valgrind and client
- At startup, depending on the view we have
of the address space (scanned), command-line
options, whatever, we decide a layout
and fix (compute) the hard limits.
- The big file mapping areas is between the client heap
and a shared area which is used in last resort.
- At runtime, we arbitrate the allocations in the shared
areas. For previous model, we would first try
to use everything in SA1 before using SA2 because
it impacts client heap and max mappable file size.
- If something goes wrong, we issue a clear message
telling the user to increase e.g. the min avail stack
size or min avail heap size on the command-line
I re-read carefully P1 through P5 and found nothing
problematic remaining. The only question I have no answer
is why was there a barrier between vg and client. I feel
it is not needed.
> [Modularization, Unit testing, ...]
> This will require some work to improve the modularisation a bit (ie.
> decreasing coupling and making modules as self-contained as possible)
> but that's a good thing.
Clearly a big task which could really improve the quality...
Volunteers ? ;-)
> But self-hosting would definitely be a good thing too.
With the shared areas, it shouldn't be too difficult
to have the 3 pseudo-processes (VG1 + VG2 + Client)
sharing the same address space. Probably with a bit of
cooperation between VG1 and VG2...
--
Eric
|
|
From: Julian S. <js...@ac...> - 2004-09-02 17:37:30
|
This is great! It's the first example I've seen of using diff to convert a picture of a cube into a picture of a 4-D hypercube. Most ingenious. :-J > - (tool_arch_asm.h?) <------- core_arch_asm.h > + > + (include/x86/tool_arch_asm.h?) <----- coregrind/x86/core_arch_asm.h > ^ ^ ^ ^ > / \ / \ > / \ / \ > - tool_asm.h <---\---------- core_asm.h \ > + / \ / \ > + include/tool_asm.h <-\---- coregrind/core_asm.h \ > ^ \ ^ \ > - \ tool_arch.h <---------\---- core_arch.h > + \ include/x86/tool_arch.h <--------coregrind/x86/core_arch.h > \ ^ \ ^ > \ / \ / > \ / \ / > - tool.h <------------------ core.h > + \ / \ / > + include/tool.h <------------ coregrind/core.h |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 16:25:55
|
CVS commit by nethercote:
Tweaked comment.
M +20 -12 core.h 1.8
--- valgrind/coregrind/core.h #1.7:1.8
@@ -50,17 +50,22 @@
This gives the following hierarchy (only showing 'arch' headers, not
- 'os' or 'platform' headers), where arrows indicate inclusion:
+ 'os' or 'platform' headers), where arrows indicate inclusion, and
+ $VG_ARCH==x86:
- (tool_arch_asm.h?) <------- core_arch_asm.h
+
+ (include/x86/tool_arch_asm.h?) <----- coregrind/x86/core_arch_asm.h
^ ^ ^ ^
/ \ / \
/ \ / \
- tool_asm.h <---\---------- core_asm.h \
+ / \ / \
+ include/tool_asm.h <-\---- coregrind/core_asm.h \
^ \ ^ \
- \ tool_arch.h <---------\---- core_arch.h
+ \ include/x86/tool_arch.h <--------coregrind/x86/core_arch.h
\ ^ \ ^
\ / \ /
\ / \ /
- tool.h <------------------ core.h
+ \ / \ /
+ include/tool.h <------------ coregrind/core.h
+
Note that core.h contains the *declarations* of arch-specific functions
@@ -70,4 +75,7 @@
there is no separation between declaration and definition for
macros/types, so they instead go into $VG_ARCH/core_arch.h.
+
+ The tool-specific headers are all in include/ so they can be seen by any
+ external tools.
*/
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 16:05:30
|
CVS commit by nethercote: Arch-abstraction: - removing the directories arch/x86-linux and arch/x86-freebsd, the contents of which were never actually used. R .cvsignore 1.1 R Makefile.am 1.3 R x86-freebsd/.cvsignore 1.1 R x86-freebsd/Makefile.am 1.1 R x86-freebsd/vg_libpthread.c 1.2 R x86-freebsd/vg_syscall.S 1.2 R x86-linux/.cvsignore 1.1 R x86-linux/Makefile.am 1.3 R x86-linux/vg_libpthread.c 1.143 R x86-linux/vg_libpthread_unimp.c 1.43 R x86-linux/vg_syscall.S 1.11 |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 16:03:09
|
CVS commit by nethercote:
Arch-abstraction: add comment explaining header hierarchy.
M +44 -4 core.h 1.7
--- valgrind/coregrind/core.h #1.6:1.7
@@ -34,8 +34,42 @@
#define __CORE_H
-/* ---------------------------------------------------------------------
- Build options and table sizes. You should be able to change these
- options or sizes, recompile, and still have a working system.
- ------------------------------------------------------------------ */
+/*
+ Header hierarchy:
+
+ - core C files include core.h
+ - core asm files include core_asm.h
+ - tool C files include tool.h
+ - tool asm files include tool_asm.h
+
+ - The hierarchy of the header files themselves is based around the
+ following rules:
+
+ - core headers include tool headers
+ - generic headers include arch/OS/platform headers
+ - C headers include asm headers
+
+ This gives the following hierarchy (only showing 'arch' headers, not
+ 'os' or 'platform' headers), where arrows indicate inclusion:
+
+ (tool_arch_asm.h?) <------- core_arch_asm.h
+ ^ ^ ^ ^
+ / \ / \
+ / \ / \
+ tool_asm.h <---\---------- core_asm.h \
+ ^ \ ^ \
+ \ tool_arch.h <---------\---- core_arch.h
+ \ ^ \ ^
+ \ / \ /
+ \ / \ /
+ tool.h <------------------ core.h
+
+ Note that core.h contains the *declarations* of arch-specific functions
+ and variables, which can be used by the core_arch.h file of any
+ architecture. (The functions/variables are *defined* within arch/.)
+ However, arch-specific macros and types cannot go into core.h, because
+ there is no separation between declaration and definition for
+ macros/types, so they instead go into $VG_ARCH/core_arch.h.
+*/
+
/* For system call numbers __NR_... */
@@ -50,4 +84,10 @@
#define SK_(x) vgSkinInternal_##x
+
+/* ---------------------------------------------------------------------
+ Build options and table sizes. You should be able to change these
+ options or sizes, recompile, and still have a working system.
+ ------------------------------------------------------------------ */
+
/* Total number of spill slots available for allocation, if a TempReg
doesn't make it into a RealReg. Just bomb the entire system if
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 15:50:37
|
CVS commit by nethercote:
Update docs for filename change.
M +1 -1 mc_techdocs.html 1.10
--- valgrind/memcheck/docs/mc_techdocs.html #1.9:1.10
@@ -391,5 +391,5 @@
globally visible symbols exported from <code>valgrind.so</code>
are defined using the <code>VG_</code> CPP macro. As you'll see
- from <code>vg_constants.h</code>, this appends some arbitrary
+ from <code>tool_asm.h</code>, this appends some arbitrary
prefix to the symbol, in order that it be, we hope, globally
unique. Currently the prefix is <code>vgPlain_</code>. For
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 15:49:15
|
CVS commit by nethercote: Tweak some comments. M +2 -5 coregrind/core.h 1.6 M +1 -1 include/tool.h.base 1.3 --- valgrind/coregrind/core.h #1.5:1.6 @@ -42,10 +42,7 @@ #include "vg_unistd.h" -#include "core_asm.h" +#include "core_asm.h" // asm stuff +#include "tool.h" // tool stuff -/* All stuff visible to core and tools goes in tool.h. Things - * visible to core but not visible to any tools should go in this - * file, core.h. */ -#include "tool.h" #include "valgrind.h" --- valgrind/include/tool.h.base #1.2:1.3 @@ -35,5 +35,5 @@ #include <setjmp.h> /* for jmp_buf */ -#include "tool_asm.h" +#include "tool_asm.h" // asm stuff // XXX: here temporarily, will eventually go in arch-specific headers... |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 15:37:45
|
CVS commit by nethercote:
Arch-abstraction:
- renamed "vg_constants.h" as "core_asm.h".
- renamed "vg_constants_skin.h" as "tool_asm.h".
- renamed "mc_constants.h" as "mc_asm.h".
A coregrind/core_asm.h 1.1 [GPL (v2+)]
A include/tool_asm.h 1.1 [GPL (v2+)]
A memcheck/mc_asm.h 1.1 [GPL (v2+)]
M +1 -1 valgrind.spec.in 1.15
M +1 -1 coregrind/Makefile.am 1.81
M +3 -3 coregrind/core.h 1.5
M +1 -1 coregrind/vg_cpuid.S 1.3
M +1 -1 coregrind/vg_dispatch.S 1.18
M +1 -1 coregrind/vg_helpers.S 1.34
M +1 -1 coregrind/vg_syscall.S 1.14
M +2 -2 include/Makefile.am 1.7
M +1 -1 include/tool.h.base 1.2
M +1 -1 memcheck/Makefile.am 1.52
M +1 -1 memcheck/mc_helpers.S 1.10
M +1 -1 memcheck/mc_include.h 1.21
R coregrind/vg_constants.h 1.17
R include/vg_constants_skin.h 1.8
R memcheck/mc_constants.h 1.4
--- valgrind/valgrind.spec.in #1.14:1.15
@@ -38,5 +38,5 @@
/usr/include/valgrind/helgrind.h
/usr/include/valgrind/tool.h
-/usr/include/valgrind/vg_constants_skin.h
+/usr/include/valgrind/tool_asm.h
/usr/include/valgrind/vg_kerneliface.h
/usr/include/valgrind/vg_skin.h
--- valgrind/coregrind/Makefile.am #1.80:1.81
@@ -141,7 +141,7 @@
noinst_HEADERS = \
core.h \
+ core_asm.h \
ume.h \
ume_arch.h \
- vg_constants.h \
vg_symtab2.h \
vg_unistd.h \
--- valgrind/coregrind/core.h #1.4:1.5
@@ -2,5 +2,5 @@
/*--------------------------------------------------------------------*/
/*--- A header file for all private parts of Valgrind's core. ---*/
-/*--- Include no other! ---*/
+/*--- Include no other! (more or less...) ---*/
/*--- core.h ---*/
/*--------------------------------------------------------------------*/
@@ -42,5 +42,5 @@
#include "vg_unistd.h"
-#include "vg_constants.h"
+#include "core_asm.h"
/* All stuff visible to core and tools goes in tool.h. Things
@@ -496,5 +496,5 @@ extern Bool VG_(is_empty_arena) ( Arena
/*
-In vg_constants.h:
+In core_asm.h:
#define VG_USERREQ__SIGNAL_RETURNS 0x4001
*/
--- valgrind/coregrind/vg_cpuid.S #1.2:1.3
@@ -30,5 +30,5 @@
*/
-#include "vg_constants.h"
+#include "core_asm.h"
#include "vg_unistd.h"
--- valgrind/coregrind/vg_dispatch.S #1.17:1.18
@@ -30,5 +30,5 @@
*/
-#include "vg_constants.h"
+#include "core_asm.h"
--- valgrind/coregrind/vg_helpers.S #1.33:1.34
@@ -29,5 +29,5 @@
*/
-#include "vg_constants.h"
+#include "core_asm.h"
/* ------------------ SIMULATED CPU HELPERS ------------------ */
--- valgrind/coregrind/vg_syscall.S #1.13:1.14
@@ -30,5 +30,5 @@
*/
-#include "vg_constants.h"
+#include "core_asm.h"
#include "vg_unistd.h"
--- valgrind/include/Makefile.am #1.6:1.7
@@ -6,7 +6,7 @@
incinc_HEADERS = \
- valgrind.h \
- vg_constants_skin.h \
tool.h \
+ tool_asm.h \
+ valgrind.h \
vg_kerneliface.h \
vg_skin.h
--- valgrind/include/tool.h.base #1.1:1.2
@@ -35,5 +35,5 @@
#include <setjmp.h> /* for jmp_buf */
-#include "vg_constants_skin.h"
+#include "tool_asm.h"
// XXX: here temporarily, will eventually go in arch-specific headers...
--- valgrind/memcheck/Makefile.am #1.51:1.52
@@ -31,5 +31,5 @@
noinst_HEADERS = \
mac_shared.h \
- mc_constants.h \
+ mc_asm.h \
mc_include.h
--- valgrind/memcheck/mc_helpers.S #1.9:1.10
@@ -30,5 +30,5 @@
*/
-#include "mc_constants.h"
+#include "mc_asm.h"
.global MC_(helper_value_check0_fail)
--- valgrind/memcheck/mc_include.h #1.20:1.21
@@ -38,5 +38,5 @@
#include "mac_shared.h"
-#include "mc_constants.h"
+#include "mc_asm.h"
/*------------------------------------------------------------*/
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 13:48:20
|
CVS commit by nethercote:
India, too
M +2 -2 overview.html 1.14
--- devel-home/valgrind/overview.html #1.13:1.14
@@ -73,6 +73,6 @@
Denmark, Finland, France, Germany, Greece, Hungary, Iceland, Italy, The
Netherlands, Norway, Poland, Russia, Sweden, Switzerland, UK,
- Argentina, Brazil, Canada, USA, Australia, Japan, New Zealand, Singapore,
- South Africa and Israel.
+ Argentina, Brazil, Canada, USA, Australia, India, Japan, New Zealand,
+ Singapore, South Africa and Israel.
<p>
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 13:47:11
|
CVS commit by nethercote:
Added gadget.
M +4 -0 users.html 1.74
--- devel-home/valgrind/users.html #1.73:1.74
@@ -199,4 +199,8 @@
<dd>Building-block libraries for quickly assembling 3D simulations, games, and
visualization applications.
+
+<dt><a href="http://www.hafro.is/gadget/">Gadget</a>
+<dd>An open source modelling framework, used to simulate and optimise
+ statistical marine ecosystem models.
</dl>
|
|
From: Paul M. <pa...@sa...> - 2004-09-02 12:23:25
|
Julian Seward writes: > > > If the machine contains a scalar 'min' insn, then we can do this cheaply > > > for any N. > > > > Yes. Is such an instruction common? > > I don't think so, at least not in scalar pipelines (SIMD ones maybe). > PaulM, what's the deal on ppc? There is no single instruction, but I believe it can be done in a few integer instructions without branches using some tricks with the carry bit (I'm sure x86 could do something similar). There are altivec instructions for signed, unsigned and floating point min and max. Paul. |
|
From: Tom H. <th...@cy...> - 2004-09-02 11:40:44
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On x86 (if we don't use seg regs) we can do
> 'cmp %limit, %addr ; cmovge %limit, %addr'
>
> which isn't great, but it isn't a disaster either, and it sounds relatively
> portable.
Bear in mind that CMOV is only available on the Pentium-Pro and
later processors. It isn't available on 486's, original Pentiums,
AMD K6's and so on. I'm not sure about the original MMX Pentiums
as I can't find one here to try it on at the moment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-09-02 11:19:23
|
> I can imagine pathological cases, under my proposal, where the client is > already very big and so V cannot find that space (ie. your "at least" > assumption fails). In those cases having incremental debug info loading > (ie. not mapping in the whole file at once) would help. However, these > cases are so unlikely that just reading in the whole file at once (which > is much simpler) should be fine. Good. I can imagine that too. So we are of common understanding. Assuming the plan goes through as proposed, I'm going to assume the debug info reading issue is a non-problem. > It might be worth me doing a summary of this thread at some point, like I > did for the threads/signals/syscalls discussion, in order to clear up any > remaining confusion and clarify our terminology. Good plan. J |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 11:17:01
|
On Thu, 2 Sep 2004, Julian Seward wrote: >>> Let's just forget about big-bang shadow allocation. It causes a whole >>> bunch of problems, we're not using it at the moment, >> >> No -- we are using it at the moment. However, we are not using >> direct-offset shadow addressing (for which big-bang shadow allocation is a >> prerequisite). Sorry if I didn't make this clear, seems like I should >> have been more careful with my terminology in the RFC. > > Uh, ok, this is my sloppy thinking. I meant, we are not using direct- > offset shadow addressing and therefore there is no reason for big-bang > shadow allocation (is there?) Correct. N |
|
From: Julian S. <js...@ac...> - 2004-09-02 11:13:18
|
> > One point to bear in mind is that the conversation that followed > > appeared to be silently predicated on the assumption that Linux is > > the only kernel we're interested in. > > Some of the stuff (using mmap()) is plain POSIX. But the stuff about > overcommitting, etc, is Linux-specific. Right. So an important thing to achieve here is to restrict our needs to plain POSIX, and have a solution independent of (eg) overcommitting hints. > In general, I'm not happy about relying on doing huge (eg. 1.5GB) mmaps. > Seems too fragile in general. I entirely agree. > > Let's just forget about big-bang shadow allocation. It causes a whole > > bunch of problems, we're not using it at the moment, > > No -- we are using it at the moment. However, we are not using > direct-offset shadow addressing (for which big-bang shadow allocation is a > prerequisite). Sorry if I didn't make this clear, seems like I should > have been more careful with my terminology in the RFC. Uh, ok, this is my sloppy thinking. I meant, we are not using direct- offset shadow addressing and therefore there is no reason for big-bang shadow allocation (is there?) > Actually, we just need one of the following to be true: > > the client must be within 0..2^N > > or > > Valgrind must be outside 0..2^N > > Ie. there could be unused address space between them, and the dividing > line just has to fall within that. > > But this seems problematic -- the only dividing line that really makes > sense for 32-bit is either 1GB or 2GB, which doesn't allow the client to > get very big. Yes, any solution which involves a single and (or nand) seems to inflexible. > > If the machine contains a scalar 'min' insn, then we can do this cheaply > > for any N. > > Yes. Is such an instruction common? I don't think so, at least not in scalar pipelines (SIMD ones maybe). PaulM, what's the deal on ppc? On x86 (if we don't use seg regs) we can do 'cmp %limit, %addr ; cmovge %limit, %addr' which isn't great, but it isn't a disaster either, and it sounds relatively portable. J |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 10:57:34
|
On Thu, 2 Sep 2004, Julian Seward wrote: > (/me is getting a bit confused here) understandable :) > Let me see if I have this right. If we simply implement Nick's > original proposal, then the whole issue of reading debug info > becomes moot because V can mmap in executables of any size to > read their debug info. At least, assuming some contiguous, > suitably large piece of virtual address space >= client_end > can be found. Correct. I can imagine pathological cases, under my proposal, where the client is already very big and so V cannot find that space (ie. your "at least" assumption fails). In those cases having incremental debug info loading (ie. not mapping in the whole file at once) would help. However, these cases are so unlikely that just reading in the whole file at once (which is much simpler) should be fine. > This is an improvement on the current situation wherein we > essentially are reserving 256M of space for more or less this > purpose (+ misc other V-internal storage), and have to fail on > executables bigger than ~200M. Correct. > Do I understand right? Yes. ---- It might be worth me doing a summary of this thread at some point, like I did for the threads/signals/syscalls discussion, in order to clear up any remaining confusion and clarify our terminology. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 10:50:38
|
On Thu, 2 Sep 2004, Julian Seward wrote: > One point to bear in mind is that the conversation that followed > appeared to be silently predicated on the assumption that Linux is > the only kernel we're interested in. Some of the stuff (using mmap()) is plain POSIX. But the stuff about overcommitting, etc, is Linux-specific. In general, I'm not happy about relying on doing huge (eg. 1.5GB) mmaps. Seems too fragile in general. > We have to think beyond that: I would love to make V available for > MacOSX, and I bet (eg) the OpenBSD folks would love to get their hands > on an x86-openbsd variant of Valgrind. Indeed, once Nick's current > commit set goes in, one interesting experiment would be to try an > openbsd port. Or freebsd (already exists) or netbsd. Definitely. Once I've finished putting the structure in place, it would be great if someone (Doug?) could create a patch for FreeBSD, like Paul has been doing for PPC. Hopefully the changes required won't be too big -- just some factoring -- in which case I don't see why it couldn't go into CVS if it's working reliably. In contrast, PPC will require UCode reworking, so that's not going to be able to go in quite yet. > Let's just forget about big-bang shadow allocation. It causes a whole > bunch of problems, we're not using it at the moment, No -- we are using it at the moment. However, we are not using direct-offset shadow addressing (for which big-bang shadow allocation is a prerequisite). Sorry if I didn't make this clear, seems like I should have been more careful with my terminology in the RFC. > and we don't have > a clear picture of where the cycle-level costs of shadow memory come > from anyway. For example, if shadow memory really kills us because > it jacks up the D1/L2 cache miss rates, then it's going to do so > regardless of the address translation scheme in use. Yes. >> 4. Maybe make the --pointer-check=no change, if it seems useful. > > Well, I like the fact that currently the client can't trash V. Yes, the default would be --pointer-check=yes, which maintains that non-trashing property. The mooted change would only take effect if you specify --pointer-check=no; that would only be used for really difficult cases where we really can't get it to work otherwise. > Another thing to consider is how to achieve this portably, on non-x86s. > If the client address space is contained entirely in 0 .. N-1, and N is > a power of two, ANDing is obviously a cheap solution. Actually, we just need one of the following to be true: the client must be within 0..2^N or Valgrind must be outside 0..2^N Ie. there could be unused address space between them, and the dividing line just has to fall within that. But this seems problematic -- the only dividing line that really makes sense for 32-bit is either 1GB or 2GB, which doesn't allow the client to get very big. > If the machine contains a scalar 'min' insn, then we can do this cheaply > for any N. Yes. Is such an instruction common? N |
|
From: Julian S. <js...@ac...> - 2004-09-02 10:35:27
|
(/me is getting a bit confused here) Let me see if I have this right. If we simply implement Nick's original proposal, then the whole issue of reading debug info becomes moot because V can mmap in executables of any size to read their debug info. At least, assuming some contiguous, suitably large piece of virtual address space >= client_end can be found. This is an improvement on the current situation wherein we essentially are reserving 256M of space for more or less this purpose (+ misc other V-internal storage), and have to fail on executables bigger than ~200M. Do I understand right? J On Wednesday 01 September 2004 22:48, Nicholas Nethercote wrote: > On Wed, 1 Sep 2004, Jeremy Fitzhardinge wrote: > >> But when Nicholas said "incremental loading", he meant loading > >> debug infos for sections/compile units as we need them. > >> That's another problem, not completely decorrelated with > >> the "I can't map the whole file to read dbg infos". > > > > Yes, I know, exactly. > > Er, no, by "incremental loading" I meant loading the debug info for a > single section in pieces, rather than requiring one big mmap(). Loading > debug info as we need them I would call "lazy" or "on-demand" loading. > Sorry if that was unclear. > > >> Not sure it's worth doing it for now. How many people still use > >> stabs (on the platform we support...) ? > > > > Valgrind's dwarf support is pretty weak compared to the stabs support - > > there's nothing there to extract type information. > > But Helgrind is the only tool that uses the type information, and not many > people use Helgrind. > > > We only need to resort to padding things out either before we gain full > > control (constraining ld.so to put things in the right place) > > I'm surprised that people with non-overcommitting kernels are not having a > problem with this step, but are having a problem with the big-bang shadow > memory allocation. I would have thought the padding done by stage1 would > involve more than 1.5GB worth of maps. > > >> BTW, now we are speaking of mem layout, I think it is very important > >> to keep in mind that it would be great to bootstrap V... > > > > You mean self-virtualization? That's a goal, but its tricky. > > PIE should help, though. > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2004-09-02 10:24:06
|
One point to bear in mind is that the conversation that followed appeared to be silently predicated on the assumption that Linux is the only kernel we're interested in. We have to think beyond that: I would love to make V available for MacOSX, and I bet (eg) the OpenBSD folks would love to get their hands on an x86-openbsd variant of Valgrind. Indeed, once Nick's current commit set goes in, one interesting experiment would be to try an openbsd port. Or freebsd (already exists) or netbsd. > --------------------------------------------------------------------------- >-- Problems + solutions > --------------------------------------------------------------------------- >-- P1. It assumes 3G:1G user/kernel split. > > - For 4G kernels, Valgrind gets the whole extra 1GB for its own use (I > think). This works, but is sub-optimal. > > - For other layouts (eg. 2G:2G, or even 2.9G:1.1G) it just doesn't work. > Changing KICKSTART_BASE is a workaround, if you know that. (But 2G:2G > still cannot run Memcheck, see below.) > > S1. This can be solved easily, by using position-independent executables > (PIE). We can do a configure-time test for PIE, and if supported, make > stage2 a PIE. Then stage1 can decide where stage2 should go, by doing > some kind of run-time test (which would look at where the stack is, or > use shmat(), or something, to determine where the user/kernel division > lies). > > This change is pretty uncontroversial, and Paul already has a patch for > it (which I don't think should be committed as-is, but is a good start). > > For non-PIE-supporting systems, we could build 3 or 4 versions of > stage2, and choose the most appropriate one (I have a patch for this). > Or just a single fixed-location back-up stage2 might be enough. Ok, I agree with P1/S1. This is uncontroversial. Since we can't rely on PIE being around, the 3 or 4 versions solution sounds good to me. > --------------------------------------------------------------------------- >-- P2. For kernels with "overcommit" mmapping off -- which prevents a > process from allocating more address space than the available swap space -- > you need at least 1.5GB of swap for Memcheck to run, because swap must be > at least as large as any individual segment. (And I think users with > ulimit -v set suffer the same problem.) > > S2. Avoiding this requires not using the big-bang shadow allocation > method, and that shadow memory instead be done incrementally. (More about > that below.) Let's just forget about big-bang shadow allocation. It causes a whole bunch of problems, we're not using it at the moment, and we don't have a clear picture of where the cycle-level costs of shadow memory come from anyway. For example, if shadow memory really kills us because it jacks up the D1/L2 cache miss rates, then it's going to do so regardless of the address translation scheme in use. > A more radical solution: truly virtualise the address space (rather > than just partitioning it) -- ie. Valgrind implements it's own virtual > MMU and page table. The exact details of how it would work are not yet > clear. If even feasible, this is a long-term solution; something else > should be done in the meantime. I agree. Currently I do not see how to do this with a small enough performance overhead, so forget about this for the time being. > --------------------------------------------------------------------------- >-- My suggestion > --------------------------------------------------------------------------- >-- In this order, make the following changes. > > 1. Use PIE where possible, solving P1. Agree. > 2. Switch big-bang shadow memory allocation to incremental, solving P2, > P4, P5. Agree. > 3. Make the client/Valgrind division movable, largely solving P3. Agree. > 4. Maybe make the --pointer-check=no change, if it seems useful. Well, I like the fact that currently the client can't trash V. Another thing to consider is how to achieve this portably, on non-x86s. If the client address space is contained entirely in 0 .. N-1, and N is a power of two, ANDing is obviously a cheap solution. If the machine contains a scalar 'min' insn, then we can do this cheaply for any N. J |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 08:55:39
|
CVS commit by nethercote: Arch-abstraction: whoops II, forgot to add the (residual) vg_skin.h, which just points to tool.h. M +3 -2520 vg_skin.h 1.104 |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 08:54:32
|
CVS commit by nethercote: Arch-abstraction: Whoops, forgot to add tool.h.base. Also updated .cvsignore. A tool.h.base 1.1 M +1 -1 .cvsignore 1.3 --- valgrind/include/.cvsignore #1.2:1.3 @@ -1,3 +1,3 @@ Makefile.in Makefile -vg_skin.h +tool.h |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 08:51:53
|
CVS commit by nethercote:
Arch-abstraction: renamed "vg_skin.h" as "tool.h". Kept a residual vg_skin.h
(which just #includes tool.h) for backward-compatibility.
M +1 -0 valgrind.spec.in 1.14
M +1 -1 cachegrind/cg_main.c 1.77
M +1 -1 corecheck/cc_main.c 1.20
M +4 -4 coregrind/core.h 1.4
M +1 -1 coregrind/gen_toolint.pl 1.5
M +2 -2 coregrind/vg_errcontext.c 1.60
M +2 -2 coregrind/vg_instrument.c 1.14
M +1 -1 coregrind/vg_symtab2.h 1.8
M +7 -7 coregrind/docs/coregrind_tools.html 1.3
M +1 -1 helgrind/hg_main.c 1.83
M +8 -7 include/Makefile.am 1.6
M +2 -2 include/vg_profile.c 1.12
M +1 -1 lackey/lk_main.c 1.24
M +1 -1 massif/ms_main.c 1.15
M +1 -1 memcheck/mac_shared.h 1.23
M +1 -1 none/nl_main.c 1.20
R include/vg_skin.h.base 1.29
--- valgrind/valgrind.spec.in #1.13:1.14
@@ -37,4 +37,5 @@
/usr/include/valgrind/memcheck.h
/usr/include/valgrind/helgrind.h
+/usr/include/valgrind/tool.h
/usr/include/valgrind/vg_constants_skin.h
/usr/include/valgrind/vg_kerneliface.h
--- valgrind/cachegrind/cg_main.c #1.76:1.77
@@ -30,5 +30,5 @@
*/
-#include "vg_skin.h"
+#include "tool.h"
//#include "vg_profile.c"
--- valgrind/corecheck/cc_main.c #1.19:1.20
@@ -30,5 +30,5 @@
*/
-#include "vg_skin.h"
+#include "tool.h"
void SK_(pre_clo_init)(void)
--- valgrind/coregrind/core.h #1.3:1.4
@@ -44,8 +44,8 @@
#include "vg_constants.h"
-/* All stuff visible to core and tools goes in vg_skin.h. Things
+/* All stuff visible to core and tools goes in tool.h. Things
* visible to core but not visible to any tools should go in this
* file, core.h. */
-#include "vg_skin.h"
+#include "tool.h"
#include "valgrind.h"
@@ -286,5 +286,5 @@ extern void VGP_(done_profiling) ( void
/* These structs are not exposed to tools to mitigate possibility of
binary-incompatibilities when the core/tool interface changes. Instead,
- set functions are provided (see include/vg_skin.h). */
+ set functions are provided (see include/tool.h). */
typedef
struct {
@@ -1620,5 +1620,5 @@ extern Int VGOFF_(ldt);
extern Int VGOFF_(tls_ptr);
-/* Nb: Most helper offsets are in include/vg_skin.h, for use by tools */
+/* Nb: Most helper offsets are in include/tool.h, for use by tools */
extern Int VGOFF_(helper_undefined_instruction);
--- valgrind/coregrind/gen_toolint.pl #1.4:1.5
@@ -141,5 +141,5 @@
$indent = " ";
} elsif ($output eq "initfunc") {
- $include = "vg_skin.h";
+ $include = "tool.h";
$generate = sub ($$$@) {
my ($pfx, $ret, $func, @args) = @_;
--- valgrind/coregrind/vg_errcontext.c #1.59:1.60
@@ -68,5 +68,5 @@ typedef
enum (with element values in the normal range (0..)) for `ekind'.
Functions for getting/setting the tool-relevant fields are in
- include/vg_skin.h.
+ include/tool.h.
When errors are found and recorded with VG_(maybe_record_error)(), all
@@ -141,5 +141,5 @@ typedef
/* Suppressions. Tools can get/set tool-relevant parts with functions
- declared in include/vg_skin.h. Extensible via the 'extra' field.
+ declared in include/tool.h. Extensible via the 'extra' field.
Tools can use a normal enum (with element values in the normal range
(0..)) for `skind'. */
--- valgrind/coregrind/vg_instrument.c #1.13:1.14
@@ -30,9 +30,9 @@
*/
-/* We only import vg_skin.h here, because this file only provides functions
+/* We only import tool.h here, because this file only provides functions
for doing things that could be done directly by the tool -- it's just to
make tools' lives easier, rather than let them do something they
couldn't otherwise do. */
-#include "vg_skin.h"
+#include "tool.h"
--- valgrind/coregrind/vg_symtab2.h #1.7:1.8
@@ -119,5 +119,5 @@ struct _ScopeRange {
/* A structure which contains information pertaining to one mapped
- text segment. (typedef in vg_skin.h) */
+ text segment. (typedef in tool.h) */
struct _SegInfo {
struct _SegInfo* next; /* list of SegInfos */
--- valgrind/coregrind/docs/coregrind_tools.html #1.2:1.3
@@ -463,5 +463,5 @@
functions requires some work, it's much less than doing error handling from
scratch because the core is doing most of the work. See the type
-<code>VgNeeds</code> in <code>include/vg_skin.h</code> for full details of all
+<code>VgNeeds</code> in <code>include/tool.h</code> for full details of all
the needs.<p>
@@ -479,5 +479,5 @@
More information about ``details'', ``needs'' and ``trackable events'' can be
-found in <code>include/vg_skin.h</code>.<p>
+found in <code>include/tool.h</code>.<p>
<a name="instr"></a>
@@ -513,5 +513,5 @@
undoubtedly many others that I should note but haven't thought of.<p>
-The file <code>include/vg_skin.h</code> contains all the types,
+The file <code>include/tool.h</code> contains all the types,
macros, functions, etc. that a tool should (hopefully) need, and is the only
<code>.h</code> file a tool should need to <code>#include</code>.<p>
@@ -520,5 +520,5 @@
are deep reasons for this, trust us). Valgrind provides an implementation of a
reasonable subset of the C library, details of which are in
-<code>vg_skin.h</code>.<p>
+<code>tool.h</code>.<p>
Similarly, when writing a tool, you shouldn't need to look at any of the code
@@ -526,5 +526,5 @@
something.<p>
-<code>vg_skin.h</code> has a reasonable amount of documentation in it that
+<code>tool.h</code> has a reasonable amount of documentation in it that
should hopefully be enough to get you going. But ultimately, the tools
distributed (Memcheck, Addrcheck, Cachegrind, Lackey, etc.) are probably the
@@ -582,5 +582,5 @@
If you just want to know whether a program point has been reached, using the
-<code>OINK</code> macro (in <code> include/vg_skin.h</code>) can be easier than
+<code>OINK</code> macro (in <code> include/tool.h</code>) can be easier than
using GDB.<p>
@@ -690,5 +690,5 @@
<code>VGP_PUSHCC</code> and <code>VGP_POPCC</code> macros to record time spent
doing certain things. New profiling event numbers must not overlap with the
-core profiling event numbers. See <code>include/vg_skin.h</code> for details
+core profiling event numbers. See <code>include/tool.h</code> for details
and Memcheck for an example.
--- valgrind/helgrind/hg_main.c #1.82:1.83
@@ -30,5 +30,5 @@
*/
-#include "vg_skin.h"
+#include "tool.h"
#include "helgrind.h"
--- valgrind/include/Makefile.am #1.5:1.6
@@ -1,5 +1,5 @@
EXTRA_DIST = \
vg_profile.c \
- vg_skin.h.base
+ tool.h.base
incincdir = $(includedir)/valgrind
@@ -8,14 +8,15 @@
valgrind.h \
vg_constants_skin.h \
- vg_skin.h \
- vg_kerneliface.h
+ tool.h \
+ vg_kerneliface.h \
+ vg_skin.h
-BUILT_SOURCES = vg_skin.h
-CLEANFILES = vg_skin.h
+BUILT_SOURCES = tool.h
+CLEANFILES = tool.h
-vg_skin.h: $(srcdir)/vg_skin.h.base \
+tool.h: $(srcdir)/tool.h.base \
$(top_srcdir)/coregrind/gen_toolint.pl $(top_srcdir)/coregrind/toolfuncs.def
rm -f $@
- cat $(srcdir)/vg_skin.h.base > $@
+ cat $(srcdir)/tool.h.base > $@
$(PERL) $(top_srcdir)/coregrind/gen_toolint.pl toolproto < $(top_srcdir)/coregrind/toolfuncs.def >> $@ || rm -f $@
$(PERL) $(top_srcdir)/coregrind/gen_toolint.pl initproto < $(top_srcdir)/coregrind/toolfuncs.def >> $@ || rm -f $@
--- valgrind/include/vg_profile.c #1.11:1.12
@@ -35,5 +35,5 @@
#define __VG_PROFILE_C
-#include "vg_skin.h"
+#include "tool.h"
/* get rid of these, if possible */
@@ -41,5 +41,5 @@
#include <sys/time.h>
-/* Override the empty definitions from vg_skin.h */
+/* Override the empty definitions from tool.h */
#undef VGP_PUSHCC
#undef VGP_POPCC
--- valgrind/lackey/lk_main.c #1.23:1.24
@@ -30,5 +30,5 @@
*/
-#include "vg_skin.h"
+#include "tool.h"
/* Nb: use ULongs because the numbers can get very big */
--- valgrind/massif/ms_main.c #1.14:1.15
@@ -35,5 +35,5 @@
// structures below for more info on how things work.
-#include "vg_skin.h"
+#include "tool.h"
//#include "vg_profile.c"
--- valgrind/memcheck/mac_shared.h #1.22:1.23
@@ -37,5 +37,5 @@
#define __MAC_SHARED_H
-#include "vg_skin.h"
+#include "tool.h"
#define MAC_(str) VGAPPEND(vgMAC_,str)
--- valgrind/none/nl_main.c #1.19:1.20
@@ -29,5 +29,5 @@
*/
-#include "vg_skin.h"
+#include "tool.h"
void SK_(pre_clo_init)(void)
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 08:18:14
|
CVS commit by nethercote: Remove unnecessary #include statement. M +0 -1 vg_replace_malloc.c.base 1.6 --- valgrind/coregrind/vg_replace_malloc.c.base #1.5:1.6 @@ -44,5 +44,4 @@ #include "valgrind.h" /* for VALGRIND_NON_SIMD_CALL[12] */ #include "core.h" -#include "vg_skin.h" #define LIBALIAS(ret, name, args) \ |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 08:12:42
|
On Thu, 2 Sep 2004, Robert Walsh wrote: > CVS commit by rjwalsh: > > Fix some vg_include.h references. Sorry, that was stupid of me. I fixed a couple more now, I'm pretty sure that's all of them. N |