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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(32) |
2
(22) |
3
(47) |
4
(29) |
5
(18) |
6
(16) |
|
7
(21) |
8
(29) |
9
(23) |
10
(68) |
11
(20) |
12
(17) |
13
(17) |
|
14
(27) |
15
(26) |
16
(21) |
17
(13) |
18
(19) |
19
(29) |
20
(13) |
|
21
(9) |
22
(8) |
23
(29) |
24
(56) |
25
(21) |
26
(46) |
27
(33) |
|
28
(25) |
29
(41) |
30
(35) |
31
(28) |
|
|
|
|
From: Tom H. <th...@cy...> - 2005-08-27 02:24:59
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-08-27 03:10:07 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 186 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-27 02:23:41
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-08-27 03:00:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2005-08-27 02:20:10
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-08-27 03:10:07 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-27 02:16:41
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-08-27 03:05:10 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 164 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) |
|
From: Julian S. <js...@ac...> - 2005-08-27 01:19:27
|
As of r4532 I believe (famous last words TM) I have now got it in a state where valgrind_memcheck will now link and work on both x86 and amd64. At least it does for me. Shout if it's still broken. J |
|
From: <sv...@va...> - 2005-08-27 01:10:20
|
Author: sewardj
Date: 2005-08-27 02:10:17 +0100 (Sat, 27 Aug 2005)
New Revision: 4532
Log:
- move the sans-glibc startup stuff to the end of the file and
add more comments
- add implementations of memcpy and memset since they may be
needed when not linking against glibc
Modified:
branches/ASPACEM/coregrind/m_main.c
Modified: branches/ASPACEM/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_main.c 2005-08-27 00:36:11 UTC (rev 4531=
)
+++ branches/ASPACEM/coregrind/m_main.c 2005-08-27 01:10:17 UTC (rev 4532=
)
@@ -211,69 +211,9 @@
/*=3D=3D=3D Address space determination =
=3D=3D=3D*/
/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
=20
-/* Glibc's sysdeps/i386/elf/start.S has the following gem of a
- comment, which explains how the stack looks right at process start
- (when _start is jumped to). Hence _start passes %esp to
- _start_in_C, which extracts argc/argv/envp and starts up
- correctly. */
-
-/* This is the canonical entry point, usually the first thing in the tex=
t
- segment. The SVR4/i386 ABI (pages 3-31, 3-32) says that when the ent=
ry
- point runs, most registers' values are unspecified, except for:
-
- %edx Contains a function pointer to be registered with `atexi=
t'.
- This is how the dynamic linker arranges to have DT_FINI
- functions called for shared libraries that have been loa=
ded
- before this code runs.
-
- %esp The stack contains the arguments and environment:
- 0(%esp) argc
- 4(%esp) argv[0]
- ...
- (4*argc)(%esp) NULL
- (4*(argc+1))(%esp) envp[0]
- ...
- NULL
-*/
-
+// defined at the end of this file
extern char _start[];
=20
-#if defined(VGP_x86_linux)
-asm("\n"
- "\t.globl _start\n"
- "\t.type _start,@function\n"
- "_start:\n"
- "\tmovl %esp,%eax\n"
- "\tpushl %eax\n"
- "\tcall _start_in_C\n"
- "\thlt\n"
-);
-#elif defined(VGP_amd64_linux)
-asm("\n"
- "\t.globl _start\n"
- "\t.type _start,@function\n"
- "_start:\n"
- "\tmovq %rsp,%rdi\n"
- "\tcall _start_in_C\n"
- "\thlt\n"
-);
-#else
-#error "_start: needs implementation on this platform"
-#endif
-
-extern Int main (Int argc, HChar **argv, HChar **envp);
-
-static void _start_in_C ( UWord* pArgc )
-{
- Word argc =3D pArgc[0];
- HChar** argv =3D (HChar**)&pArgc[1];
- HChar** envp =3D (HChar**)&pArgc[1+argc+1];
- Int r =3D main( (Int)argc, argv, envp );
- VG_(exit)(r);
-}
-
-///////////////////////////////////////////////////////////////
-
static void layout_remaining_space(Addr argc_addr, float ratio)
{
SysRes res;
@@ -2908,6 +2848,102 @@
}
=20
=20
+/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
+/*=3D=3D=3D Getting to main() alive =
=3D=3D=3D*/
+/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
+
+/* If linking of the final executables is done with glibc present,
+ then Valgrind starts at main() above as usual, and all of the
+ following code is irrelevant.
+
+ However, this is not the intended mode of use. The plan is to
+ avoid linking against glibc, by giving gcc the flags=20
+ -nodefaultlibs -lgcc -nostartfiles at startup.
+
+ From this derive two requirements:
+
+ 1. gcc may emit calls to memcpy and memset to deal with structure
+ assignments etc. Since we have chosen to ignore all the
+ "normal" supporting libraries, we have to provide our own
+ implementations of them. No problem.
+
+ 2. We have to provide a symbol "_start", to which the kernel
+ hands control at startup. Hence the code below.
+*/
+
+/* ---------------- Requirement 1 ---------------- */
+
+void* memcpy(void *dest, const void *src, size_t n) {
+ return VG_(memcpy)(dest,src,n);
+}
+void* memset(void *s, int c, size_t n) {
+ return VG_(memset)(s,c,n);
+}
+
+/* ---------------- Requirement 2 ---------------- */
+
+/* Glibc's sysdeps/i386/elf/start.S has the following gem of a
+ comment, which explains how the stack looks right at process start
+ (when _start is jumped to). Hence _start passes %esp to
+ _start_in_C, which extracts argc/argv/envp and starts up
+ correctly. */
+
+/* This is the canonical entry point, usually the first thing in the tex=
t
+ segment. The SVR4/i386 ABI (pages 3-31, 3-32) says that when the ent=
ry
+ point runs, most registers' values are unspecified, except for:
+
+ %edx Contains a function pointer to be registered with `atexi=
t'.
+ This is how the dynamic linker arranges to have DT_FINI
+ functions called for shared libraries that have been loa=
ded
+ before this code runs.
+
+ %esp The stack contains the arguments and environment:
+ 0(%esp) argc
+ 4(%esp) argv[0]
+ ...
+ (4*argc)(%esp) NULL
+ (4*(argc+1))(%esp) envp[0]
+ ...
+ NULL
+*/
+
+/* The kernel hands control to _start, which extracts the initial
+ stack pointer and calls onwards to _start_in_C. */
+#if defined(VGP_x86_linux)
+asm("\n"
+ "\t.globl _start\n"
+ "\t.type _start,@function\n"
+ "_start:\n"
+ "\tmovl %esp,%eax\n"
+ "\tpushl %eax\n"
+ "\tcall _start_in_C\n"
+ "\thlt\n"
+);
+#elif defined(VGP_amd64_linux)
+asm("\n"
+ "\t.globl _start\n"
+ "\t.type _start,@function\n"
+ "_start:\n"
+ "\tmovq %rsp,%rdi\n"
+ "\tcall _start_in_C\n"
+ "\thlt\n"
+);
+#else
+#error "_start: needs implementation on this platform"
+#endif
+
+/* Avoid compiler warnings: this fn _is_ used, but labelling it
+ 'static' causes gcc to complain it isn't. */
+void _start_in_C ( UWord* pArgc );
+void _start_in_C ( UWord* pArgc )
+{
+ Word argc =3D pArgc[0];
+ HChar** argv =3D (HChar**)&pArgc[1];
+ HChar** envp =3D (HChar**)&pArgc[1+argc+1];
+ Int r =3D main( (Int)argc, argv, envp );
+ VG_(exit)(r);
+}
+
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
|
|
From: <sv...@va...> - 2005-08-27 00:36:21
|
Author: sewardj
Date: 2005-08-27 01:36:11 +0100 (Sat, 27 Aug 2005)
New Revision: 4531
Log:
Try to fix _start_in_C so that it works for both 32- and 64-bit platforms=
.
Modified:
branches/ASPACEM/coregrind/m_main.c
Modified: branches/ASPACEM/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_main.c 2005-08-26 23:09:00 UTC (rev 4530=
)
+++ branches/ASPACEM/coregrind/m_main.c 2005-08-27 00:36:11 UTC (rev 4531=
)
@@ -263,12 +263,12 @@
=20
extern Int main (Int argc, HChar **argv, HChar **envp);
=20
-static void _start_in_C ( ULong* pArgc )
+static void _start_in_C ( UWord* pArgc )
{
- Int argc =3D pArgc[0];
+ Word argc =3D pArgc[0];
HChar** argv =3D (HChar**)&pArgc[1];
HChar** envp =3D (HChar**)&pArgc[1+argc+1];
- Int r =3D main(argc,argv,envp);
+ Int r =3D main( (Int)argc, argv, envp );
VG_(exit)(r);
}
=20
|
|
From: Julian S. <js...@ac...> - 2005-08-27 00:25:05
|
> > VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes > > failed. VG_(get_memory_from_mmap): 0 bytes already allocated. Ah. Welcome to bootstrap allocator hell. This is what happens if you try and use VG_(malloc) before aspacemgr is able to deal with the resulting anonymous mmap. > This was triggered by my having a .valgrindrc file. Without it I can > get beyond that. Now it crashes if I valgrind "uname -a" but if I add > a -d switch to valgrind it works... I don't know if it's related, but I thought this a bit odd .. -static void _start_in_C ( Int* pArgc ) +static void _start_in_C ( ULong* pArgc ) Shouldn't that be a UWord* pArgc ? Since the location of argv/envp is determined in word-offsets from &pArgc[0], so changing it to a ULong* will screw up the computation on a 32-bit machine? J |