You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Eric E. <eri...@fr...> - 2004-08-21 22:25:30
|
Tom Hughes wrote: > Is this not what the reording of the header that I did the other day > was supposed to fix? or has that reordering broken it? Effectively. Mea culpa, I may have forgotten to run autogen.sh before configure :-P -- Eric |
|
From: Tom H. <th...@cy...> - 2004-08-21 22:00:33
|
In message <412...@fr...>
Eric Estievenart <eri...@fr...> wrote:
> FYI, on my machine, in asm/ipc.h, struct ipc_kludge is defines as follows:
>
> struct ipc_kludge {
> struct msgbuf __user *msgp;
> long msgtyp;
> };
>
> Which makes the compilation fail due to __user.
>
> I added
> #define __user
>
> just before
> #include <linux/msg.h> /* for struct msgbuf */
>
> in vg_unsafe.h for it to compile.
Is this not what the reording of the header that I did the other day
was supposed to fix? or has that reordering broken it?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Eric E. <eri...@fr...> - 2004-08-21 21:16:15
|
FYI, on my machine, in asm/ipc.h, struct ipc_kludge is defines as follows:
struct ipc_kludge {
struct msgbuf __user *msgp;
long msgtyp;
};
Which makes the compilation fail due to __user.
I added
#define __user
just before
#include <linux/msg.h> /* for struct msgbuf */
in vg_unsafe.h for it to compile.
Cheers
-- Eric
|
|
From: Bob F. <bfr...@si...> - 2004-08-21 18:42:37
|
On Sat, 21 Aug 2004, Nicholas Nethercote wrote: > > It's a good question -- what does using automake give us? I'm sure it has > some nice things (I think it works out dependencies automatically?) Perhaps > someone can list the advantages of using it over hand-writing > Makefile.in files. Provides: * Assures make target conformance with GNU standards. * Encapsulates GNU standard prefix install rules. * Provides a framework to encapsulate test suites. * Works with any `make' program, not just GNU make. * Includes platform portability tweaks. * Integrated with libtool. * Conditional statements in Makefile.am. * Automatic dependency generation (including proprietary compilers). * Automatically imports configure definitions as Makefile variables. * Provides a simple syntax to install files into any directory. * Provides a solid 'dist' target. * Provides a self-validating 'distcheck' target. * Works well with VPATH builds. Does not provide: * Makefile includes. * Wildcarded sources/targets. * GNU make style functions. * Run-time make conditionals (uses configure time conditionals). There was a time when I knew every aspect of GNU make and wrote super-intelligent Makefiles by hand. I would not choose to do that now. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-08-21 17:23:53
|
>> The keys ideas are: >> >> - to very carefully identify which category all code belongs to >> - to minimise the interface between generic and non-generic code >> - to minimise code duplication by pushing code into the most generic code >> part possible > > Yes, this is certainly the goal. I don't think we are going to get > this right from the beginning though, so we will have to allow it to > evolve. I'll take another look and work out a more detailed proposal, since nobody seems to think the basic outline is drastically flawed or anything. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-21 17:22:53
|
On Sat, 21 Aug 2004, Bob Friesenhahn wrote: >> Are people wedded to the GNU standards for Makefiles and/or to using >> automake? If so then we absolutely need an automake expert. >> Otherwise we could try to come up with something hopefully a bit >> simpler that would do what we need. > > Automake is really not very complicated and is sufficiently powerful to > handle building Valgrind. > > Nicholas did set up a single Automake Makefile.am to build Valgrind but he > didn't like the way options were applied so the work was shelved. It seems > that no more than a day of effort was expended. Maybe a bit more than a day. Yes, compiling different C files with different compiler options was a problem -- it's easy to set the flags for all files, or for one, but not for a subset. Also, I just couldn't get everything to work properly. It seemed like in theory it all made sense, but there were enough difficult details that I gave up, because the benefits were not very significant. It's a good question -- what does using automake give us? I'm sure it has some nice things (I think it works out dependencies automatically?) Perhaps someone can list the advantages of using it over hand-writing Makefile.in files. >> * Setting up symlinks so that the headers for the architecture we're >> building for get included. On the whole I prefer symlinks to using >> multiple -I flags (but I don't know how to get automake to create >> the symlinks). > > Automake will pass through normal `make' rules so it is easy to create > symlinks. I believe that using symlinks is not the right approach though > since it is not completely portable and the -I flag mechanism is very easy to > tailor from the configure script and through make variables. symlinks vs. -I does not seem like a big deal to me. We already use both in different circumstances. It's not hard to switch between them. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-21 17:17:26
|
On Sat, 21 Aug 2004, Paul Mackerras wrote: > Yes. There may also be some code that depends on the executable > format which is shared across several platforms, for example, ELF is > used on x86-linux, ppc-linux, x86-freebsd I presume, but not > ppc-macosx (which AFAIK uses mach-o). Hmm, I'll think about that. > Looked good to me, although you don't say what to do with the > platform-specific definitions in the files in include/. Do we have a > set of platform directories under include as well as the set under > coregrind, or do we try to keep it down to one set of platform- > specific directories? Yes, not sure about that. Currently we have tool-visible headers (eg. vg_skin.h) in include/ and others (eg. vg_include.h) in coregrind/. I'll think about that too. > BTW, is the VG_() for external symbols in fashion or out of fashion at > the moment? I know I haven't been consistent about using or not using > that. AFAIK all external symbols do have VG_() (or SK_() or VGP_()) prefixed. It's not as necessary now that we have full virtualisation and Valgrind is effectively in a separate namespace from the client, although we do still have internal versions of many glibc functions. Also, I like that it makes clear what's external. And it's consistent. N |
|
From: Bob F. <bfr...@si...> - 2004-08-21 14:34:24
|
On Sat, 21 Aug 2004, Paul Mackerras wrote: > > Are people wedded to the GNU standards for Makefiles and/or to using > automake? If so then we absolutely need an automake expert. > Otherwise we could try to come up with something hopefully a bit > simpler that would do what we need. Automake is really not very complicated and is sufficiently powerful to handle building Valgrind. Nicholas did set up a single Automake Makefile.am to build Valgrind but he didn't like the way options were applied so the work was shelved. It seems that no more than a day of effort was expended. > The main challenges I see in building valgrind are: > > * Setting up symlinks so that the headers for the architecture we're > building for get included. On the whole I prefer symlinks to using > multiple -I flags (but I don't know how to get automake to create > the symlinks). Automake will pass through normal `make' rules so it is easy to create symlinks. I believe that using symlinks is not the right approach though since it is not completely portable and the -I flag mechanism is very easy to tailor from the configure script and through make variables. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Tom H. <th...@cy...> - 2004-08-21 11:10:57
|
CVS commit by thughes:
Add support for a --time-stamp option that causes each message output
by valgrind to include a time stamp. This fixes bug #70587.
M +3 -0 coregrind/vg_include.h 1.234
M +4 -0 coregrind/vg_main.c 1.195
M +28 -2 coregrind/vg_messages.c 1.14
M +6 -0 coregrind/docs/coregrind_core.html 1.33
M +1 -0 none/tests/cmdline1.stdout.exp 1.7
M +1 -0 none/tests/cmdline2.stdout.exp 1.7
--- valgrind/coregrind/vg_include.h #1.233:1.234
@@ -205,4 +205,7 @@ extern Int VG_(clo_log_fd);
extern Char* VG_(clo_log_name);
+/* Add timestamps to log messages? default: NO */
+extern Bool VG_(clo_time_stamp);
+
/* The file descriptor to read for input. default: 0 == stdin */
extern Int VG_(clo_input_fd);
--- valgrind/coregrind/vg_main.c #1.194:1.195
@@ -1434,4 +1434,6 @@ Int VG_(clo_log_fd) = 1;
Char* VG_(clo_log_name) = NULL;
+Bool VG_(clo_time_stamp) = False;
+
Int VG_(clo_input_fd) = 0; /* stdin */
Int VG_(clo_n_suppressions) = 0;
@@ -1482,4 +1484,5 @@ void usage ( Bool debug_help )
" --trace-children=no|yes Valgrind-ise child processes? [no]\n"
" --track-fds=no|yes track open file descriptors? [no]\n"
+" --time-stamp=no|yes add timestamps to log messages? [no]\n"
"\n"
" uncommon user options for all Valgrind tools:\n"
@@ -1686,4 +1689,5 @@ static void process_cmd_line_options( UI
else VG_BOOL_CLO("--show-below-main", VG_(clo_show_below_main))
else VG_BOOL_CLO("--single-step", VG_(clo_single_step))
+ else VG_BOOL_CLO("--time-stamp", VG_(clo_time_stamp))
else VG_BOOL_CLO("--track-fds", VG_(clo_track_fds))
else VG_BOOL_CLO("--trace-children", VG_(clo_trace_children))
--- valgrind/coregrind/vg_messages.c #1.13:1.14
@@ -33,4 +33,7 @@
#include "vg_include.h"
+#include <time.h>
+#include <sys/time.h>
+
static char vg_mbuf[M_VG_MSGBUF];
@@ -44,4 +47,22 @@ static void add_to_buf ( Char c )
}
+static void add_timestamp ( Char *buf )
+{
+ struct timeval tv;
+ struct tm tm;
+
+ if ( gettimeofday( &tv, NULL ) == 0 &&
+ localtime_r( &tv.tv_sec, &tm ) == &tm ) {
+ VG_(sprintf)( buf, "%04d-%02d-%02d %02d:%02d:%02d.%03d ",
+ tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, tv.tv_usec / 1000 );
+ }
+ else {
+ VG_(strcpy)( buf, "" );
+ }
+
+ return;
+}
+
/* Publically visible from here onwards. */
@@ -80,7 +101,12 @@ int VG_(message) ( VgMsgKind kind, Char*
int VG_(start_msg) ( VgMsgKind kind )
{
+ Char ts[32];
Char c;
vg_n_mbuf = 0;
vg_mbuf[vg_n_mbuf] = 0;
+ if (VG_(clo_time_stamp))
+ add_timestamp(ts);
+ else
+ VG_(strcpy)(ts, "");
switch (kind) {
case Vg_UserMsg: c = '='; break;
@@ -90,6 +116,6 @@ int VG_(start_msg) ( VgMsgKind kind )
default: c = '?'; break;
}
- return VG_(add_to_msg)( "%c%c%d%c%c ",
- c,c, VG_(getpid)(), c,c );
+ return VG_(add_to_msg)( "%c%c%s%d%c%c ",
+ c,c, ts, VG_(getpid)(), c,c );
}
--- valgrind/coregrind/docs/coregrind_core.html #1.32:1.33
@@ -558,4 +558,10 @@
see section <a href="#core-comment">2.3</a>.
</li><br><p>
+
+ <li><code>--time-stamp=no</code> [default]<br>
+ <code>--time-stamp=yes</code>
+ <p>Specifies that valgrind should output a timestamp before
+ each message that it outputs.
+ </li><br><p>
</ul>
--- valgrind/none/tests/cmdline1.stdout.exp #1.6:1.7
@@ -10,4 +10,5 @@
--trace-children=no|yes Valgrind-ise child processes? [no]
--track-fds=no|yes track open file descriptors? [no]
+ --time-stamp=no|yes add timestamps to log messages? [no]
uncommon user options for all Valgrind tools:
--- valgrind/none/tests/cmdline2.stdout.exp #1.6:1.7
@@ -10,4 +10,5 @@
--trace-children=no|yes Valgrind-ise child processes? [no]
--track-fds=no|yes track open file descriptors? [no]
+ --time-stamp=no|yes add timestamps to log messages? [no]
uncommon user options for all Valgrind tools:
|
|
From: Paul M. <pa...@sa...> - 2004-08-21 06:03:12
|
Nicholas Nethercote writes: > First is about commit philosophy. For changes like this, is it better to > slip these things in gradually, or do it all in one big hit? I prefer the > former; in fact I've already started doing it for Opteron a bit (eg. my > committting of the 64-bit clean version of the allocator). I like this > because it's easier to catch mistakes when using small steps, and the code > tends to get scrutinised more. Anyone disagree? I agree, I think that things should be checked in in the smallest reasonable chunks. (For some things that might still end up being moderately large though.) > Second and more important thing is that I think it is *crucial* that we > get the file/directory structure right, at the start, since this is > difficult to change once it's in place; and this is something that should > be done in one hit. The contents of the actual files aren't so hard to > change, and so can be done bit by bit. It's a pity that CVS's support for moving files is so poor, otherwise moving files around wouldn't be so much of a hassle. Intellectually I don't think that the location of a file is difficult to change, but I agree that it usually ends up being a hassle in practice. > Also, I don't like the use of #ifdefs within the Makefile.am files. > Dealing with different platforms via #ifdefs leads to night-sweats, > feeble-mindedness and delirium. /me anxiously checks himself for symptoms. :) > Nick's proposal > --------------- > > Terminology: A "platform" is a specific $ARCH/$OS pair. For every arch > and OS, there will be 4 code parts, in order of genericity: > > 1. some generic code (aka common-common) > 2a. some arch-specific, OS-independent code (aka $ARCH-common) > 2b. some arch-independent, OS-specific code (aka common-$OS) > 3. some platform-specific code (aka $ARCH-$OS) > > 2a, 2b and 3 are all "non-generic". Yes. There may also be some code that depends on the executable format which is shared across several platforms, for example, ELF is used on x86-linux, ppc-linux, x86-freebsd I presume, but not ppc-macosx (which AFAIK uses mach-o). Not that I know of anybody doing a MacOS X port at the moment, but it seems an obvious thing for somebody to attempt after the ppc-linux port is integrated. > The keys ideas are: > > - to very carefully identify which category all code belongs to > - to minimise the interface between generic and non-generic code > - to minimise code duplication by pushing code into the most generic code > part possible Yes, this is certainly the goal. I don't think we are going to get this right from the beginning though, so we will have to allow it to evolve. [description of a directory structure snipped...] Looked good to me, although you don't say what to do with the platform-specific definitions in the files in include/. Do we have a set of platform directories under include as well as the set under coregrind, or do we try to keep it down to one set of platform- specific directories? > The names might be a bit confusing, in particular I'm not sure about the > wisdom of reusing "common" in the names "arch-common" and "common-os". > Perhaps the following would be clearer (it would also be less typing): > > - arch-common --> arch > - common-os --> os > - arch-os --> arch-os > > Eg. x86/, ppc/, x86-linux/, linux/, instead of x86-common/, ppc-common/, > x86/linux, common-linux. Yes, that's nice, and I agree we can lose the arch/ level too. > Ok, now for various lower-level comments about the patch, mostly aimed at > Paul. > > - Have you tried fitting your PPC port into this structure? Does it fit? > That's a good test. Yes it does, although there are still some ifdefs left, particularly in vg_translate.c and in parts of memcheck. > - You haven't touched the x86/ directory, I see. Any reason why not? Not wanting to make too many changes at once, basically. > - The syscalls are going to need a whole lot more abstraction/factoring > than what you've done with mmap(), but as you said the patch is only a > start. Indeed, and so is vg_translate.c. > - You've used VG_(arch_...) for a lot of names. I think a new prefix, eg. > VGA_(...) would be good. We could even use different prefixes for > definitions in the arch-common, common-os and arch-os interface, and then > a different prefix for code within those non-generic parts that isn't seen > by the generic code. Or maybe that's going too far, but something like > that would be good. Sounds good. BTW, is the VG_() for external symbols in fashion or out of fashion at the moment? I know I haven't been consistent about using or not using that. > - VG_(arch_deliver_signal)() is big -- is it possible to factor out the > generic/non-generic parts better? Hmmm, the last dozen or so lines could be moved back into generic code, but anything dealing with the signal frame layout is non-generic. > - why are arch_set_arg_and_ret() and arch_thread_initial_stack() not > VG_() prefixed? I did this over an extended period of time, and at the time I was doing that it seemed that the VG_() prefix wasn't in fashion. :) I don't really mind either way very much, although simpler is always better. > - There doesn't seem to be much consistency in the file-naming scheme, eg. > some have "arch" in them, some have "x86", some don't. My proposal above > partly addresses this. Part of that was because automake got unhappy if I had two .c files with the same name in different subdirectories. That problem would be solved by having make recurse into the platform-specific directories and make .a files. The other point was that I was concentrating more about what functions the platform code needed to supply to the generic code, than on what went in what files. > - I'm not happy about vg_libpthread.c being in x86-$OS/ subdirs -- huge > parts will be shared with the x86-freebsd, etc. But maybe you copied that > from the current (misleading) coregrind/arch/x86-$OS/ directories, the > contents of which aren't actually used. I didn't touch the versions of vg_libpthread.c in x86-$OS. I moved some of coregrind/vg_libpthread.c into x86-common/vg_x86_thread.c. I agree that having a redundant version in x86-$OS is confusing. :) > - If this patch was done in small steps, is there any order you'd > prefer/suggest? Probably start with putting various #defines in platform-specific headers (e.g. what I had in vg_archconst.h). The REGPARM definition and the FIRST/LAST_ARCH_REG definitions could be added to vg_skin.h.base fairly early. Then move all the platform-specific VGOFF_() variables and their initialization and use into platform-specific files. Then tackle the platform-specific parts of ThreadState. We also need to pull out the x86-specific parts of vg_skin.h.base at some point. Then we can start on the hard parts. :) Regards, Paul. |
|
From: Tom H. <th...@cy...> - 2004-08-21 03:13:41
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-21 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow custom_alloc: valgrind -q ./custom_alloc doublefree: valgrind -q ./doublefree error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse Could not read `insn_sse.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-21 02:55:47
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-21 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 ---------------------------------------- == 173 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-08-21 02:39:38
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-21 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 ---------------------------------------- == 178 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-08-21 02:20:22
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-21 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 178 tests, 8 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) 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-08-21 02:13:17
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-21 03:10:02 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 ---------------------------------------- == 178 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-08-21 02:08:23
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-21 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 178 tests, 9 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/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Paul M. <pa...@sa...> - 2004-08-21 01:59:11
|
Nicholas Nethercote writes:
> What is the kernel's way of dealing with it -- I thought it was with
> symlinks, which is what I suggested in my dir/file proposal. Does
> Valgrind differ in some way from the kernel in this respect?
There is a symlink for include files: include/asm points to
asm-${ARCH}.
The kernel makefile system was completely reengineered for 2.6. I've
heard the new system described as a better make implemented in the
GNU-make language. :) It's pretty complex and I don't understand it
fully, but it works nicely. One of the big changes from 2.4 was that
we no longer recursively invoke make in subdirectories. Instead the
one instance of make does all the compiling and linking required.
The top-level makefile determines what architecture we are on and
assigns that to ${ARCH}. If it wasn't set by the user (for
cross-compiling) we get it from $(shell uname -m). It then includes
arch/$(ARCH)/Makefile. There's also a Makefile in each of the
top-level directories that get included. Those can add values to
obj-y and obj-m, which are either the names of .o files to build and
link in or directory names with a trailing /.
The reason for the obj-y and obj-m names is that you can then do
obj-$(CONFIG_FOO) += foo.o
where CONFIG_FOO can be n, m or y. Then there are other rules that
build in everything listed in obj-y and build modules for everything
listed in obj-m. Along the way it creates a .foo.o.cmd for every
foo.o that contains the dependencies for foo.o.
I don't think we want to use the kernel Makefile system directly but
we can possibly get some good ideas from it. One of the big
differences is that we are building a lot of separate things in
valgrind whereas the kernel makefiles are mainly aimed at building
vmlinux (though to be fair, quite a few other things get built along
the way).
Are people wedded to the GNU standards for Makefiles and/or to using
automake? If so then we absolutely need an automake expert.
Otherwise we could try to come up with something hopefully a bit
simpler that would do what we need.
The main challenges I see in building valgrind are:
* Setting up symlinks so that the headers for the architecture we're
building for get included. On the whole I prefer symlinks to using
multiple -I flags (but I don't know how to get automake to create
the symlinks).
* Building and linking in the .o files for the architecture. This
could be done by recursing into ${ARCH}-${OS} and ${ARCH}-common
directories, or it could be done just by including Makefile
fragments from those directories.
* Autogenerating dependencies.
* Having global CFLAGS that depend on the architecture and then having
extra flags for some objects.
Paul.
|