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: Paul M. <pa...@sa...> - 2004-08-22 23:21:43
|
In the course of getting Valgrind going on PowerPC, I found a couple
of bugs in find_map_space. Both of them show up when the client does
an mmap with a non-zero address but without MAP_FIXED set. I came
across them on PowerPC because we tend to map shared libraries
immediately below the executable, but they could occur on x86 as well.
The first bug occurs if the address given is less than the address of
any existing map. What happens then is that VG_(SkipNode_First)()
returns NULL. The main for loop in VG_(find_map_space)() then exits
immediately, and VG_(find_map_space)() returns 0, and the client gets
an ENOMEM error. The patch below fixes this by calling
VG_(SkipNode_First)() if VG_(SkipList_Find)() returns NULL.
The second bug is that if the client asks for an address below the
executable but the range of addresses it wants isn't free,
find_map_space will give an address just above the executable instead
of starting at VG_(client_mapbase), which is what the kernel does.
Giving an address just above the executable is bad because it
restricts the amount of memory which can be obtained with brk().
This patch fixes that by jumping up to VG_(client_mapbase) if the
address we would move up to is less than that.
Paul.
diff -urN old-cvs/coregrind/vg_memory.c valgrind-cvs/coregrind/vg_memory.c
--- old-cvs/coregrind/vg_memory.c 2004-08-11 09:37:59.000000000 +1000
+++ valgrind-cvs/coregrind/vg_memory.c 2004-08-23 08:33:01.578978112 +1000
@@ -494,9 +494,10 @@
Segment *s;
Addr ret;
Addr limit = (for_client ? VG_(client_end) : VG_(valgrind_end));
+ Addr base = (for_client ? VG_(client_mapbase) : VG_(valgrind_base));
if (addr == 0)
- addr = for_client ? VG_(client_mapbase) : VG_(valgrind_base);
+ addr = base;
else {
/* leave space for redzone and still try to get the exact
address asked for */
@@ -514,16 +515,22 @@
VG_(printf)("find_map_space: ret starts as %p-%p client=%d\n",
ret, ret+len, for_client);
- for(s = VG_(SkipList_Find)(&sk_segments, &ret);
- s != NULL && s->addr < (ret+len);
+ s = VG_(SkipList_Find)(&sk_segments, &ret);
+ if (s == NULL)
+ s = VG_(SkipNode_First)(&sk_segments);
+
+ for(; s != NULL && s->addr < (ret+len);
s = VG_(SkipNode_Next)(&sk_segments, s))
{
if (debug)
VG_(printf)("s->addr=%p len=%d (%p) ret=%p\n",
s->addr, s->len, s->addr+s->len, ret);
- if (s->addr < (ret + len) && (s->addr + s->len) > ret)
+ if (s->addr < (ret + len) && (s->addr + s->len) > ret) {
ret = s->addr+s->len;
+ if (ret < base - VKI_BYTES_PER_PAGE)
+ ret = base - VKI_BYTES_PER_PAGE;
+ }
}
if (debug) {
|
|
From: Tom H. <th...@cy...> - 2004-08-22 22:56:37
|
CVS commit by thughes:
More fixes for the cancellation wrappers in libpthread - if looking
for the original function with RTLD_NEXT doesn't work then try looking
for the __libc_ version of the function the RTLD_DEFAULT instead.
The reason for this is that, contrary to the dlsym documentation, it
seems that RTLD_NEXT doesn't always seem to find the definition that
would have been used if it weren't for the override. This is particularly
common wihen libpthread is pulled in implicitly by a dependency from
another library.
This should hopefully fix bug #85658.
M +44 -39 vg_libpthread.c 1.160
--- valgrind/coregrind/vg_libpthread.c #1.159:1.160
@@ -2243,10 +2243,11 @@ void ** (*__libc_internal_tsd_address)
------------------------------------------------------------------ */
-#define FORWARD(name, args...) \
+#define FORWARD(name, altname, args...) \
({ \
static name##_t name##_ptr = NULL; \
if (name##_ptr == NULL) { \
- name##_ptr = (name##_t)dlsym(RTLD_NEXT, #name); \
- my_assert(name##_ptr != NULL); \
+ if ((name##_ptr = (name##_t)dlsym(RTLD_NEXT, #name)) == NULL) \
+ name##_ptr = (name##_t)dlsym(RTLD_DEFAULT, #altname); \
+ my_assert(name##_ptr != NULL && name##_ptr != name); \
} \
name##_ptr(args); \
@@ -2263,5 +2264,9 @@ int sigaction(int signum,
{
__my_pthread_testcancel();
- return FORWARD(sigaction, signum, act, oldact);
+#ifdef GLIBC_2_1
+ return FORWARD(sigaction, __sigaction, signum, act, oldact);
+#else
+ return FORWARD(sigaction, __libc_sigaction, signum, act, oldact);
+#endif
}
@@ -2273,5 +2278,5 @@ int accept(int fd, struct sockaddr *addr
{
__my_pthread_testcancel();
- return FORWARD(accept, fd, addr, len);
+ return FORWARD(accept, __libc_accept, fd, addr, len);
}
@@ -2286,5 +2291,5 @@ int connect(int sockfd,
{
__my_pthread_testcancel();
- return FORWARD(connect, sockfd, serv_addr, addrlen);
+ return FORWARD(connect, __libc_connect, sockfd, serv_addr, addrlen);
}
@@ -2296,5 +2301,5 @@ int fcntl(int fd, int cmd, long arg)
{
__my_pthread_testcancel();
- return FORWARD(fcntl, fd, cmd, arg);
+ return FORWARD(fcntl, __libc_fcntl, fd, cmd, arg);
}
@@ -2306,5 +2311,5 @@ ssize_t write(int fd, const void *buf, s
{
__my_pthread_testcancel();
- return FORWARD(write, fd, buf, count);
+ return FORWARD(write, __libc_write, fd, buf, count);
}
@@ -2316,5 +2321,5 @@ ssize_t read(int fd, void *buf, size_t c
{
__my_pthread_testcancel();
- return FORWARD(read, fd, buf, count);
+ return FORWARD(read, __libc_read, fd, buf, count);
}
@@ -2324,5 +2329,5 @@ int (*open64_t)(const char *pathname, in
int open64(const char *pathname, int flags, mode_t mode)
{
- return FORWARD(open64, pathname, flags, mode);
+ return FORWARD(open64, __libc_open64, pathname, flags, mode);
}
@@ -2332,5 +2337,5 @@ int (*open_t)(const char *pathname, int
int open(const char *pathname, int flags, mode_t mode)
{
- return FORWARD(open, pathname, flags, mode);
+ return FORWARD(open, __libc_open, pathname, flags, mode);
}
@@ -2341,5 +2346,5 @@ int close(int fd)
{
__my_pthread_testcancel();
- return FORWARD(close, fd);
+ return FORWARD(close, __libc_close, fd);
}
@@ -2351,15 +2356,15 @@ pid_t waitpid(pid_t pid, int *status, in
{
__my_pthread_testcancel();
- return FORWARD(waitpid, pid, status, options);
+ return FORWARD(waitpid, __libc_waitpid, pid, status, options);
}
typedef
-int (*nanosleep_t)(const struct timespec *req, struct timespec *rem);
+int (*__nanosleep_t)(const struct timespec *req, struct timespec *rem);
WEAK
int __nanosleep(const struct timespec *req, struct timespec *rem)
{
__my_pthread_testcancel();
- return FORWARD(nanosleep, req, rem);
+ return FORWARD(__nanosleep, __libc_nanosleep, req, rem);
}
@@ -2367,18 +2372,18 @@ typedef
int (*pause_t)(void);
WEAK
-int __pause(void)
+int pause(void)
{
__my_pthread_testcancel();
- return FORWARD(pause);
+ return FORWARD(pause, __libc_pause);
}
typedef
-int (*tcdrain_t)(int fd);
+int (*__tcdrain_t)(int fd);
WEAK
int __tcdrain(int fd)
{
__my_pthread_testcancel();
- return FORWARD(tcdrain, fd);
+ return FORWARD(__tcdrain, __libc_tcdrain, fd);
}
@@ -2390,5 +2395,5 @@ int fsync(int fd)
{
__my_pthread_testcancel();
- return FORWARD(fsync, fd);
+ return FORWARD(fsync, __libc_fsync, fd);
}
@@ -2400,5 +2405,5 @@ off_t lseek(int fildes, off_t offset, in
{
__my_pthread_testcancel();
- return FORWARD(lseek, fildes, offset, whence);
+ return FORWARD(lseek, __libc_lseek, fildes, offset, whence);
}
@@ -2410,5 +2415,5 @@ __off64_t lseek64(int fildes, __off64_t
{
__my_pthread_testcancel();
- return FORWARD(lseek64, fildes, offset, whence);
+ return FORWARD(lseek64, __libc_lseek64, fildes, offset, whence);
}
@@ -2421,5 +2426,5 @@ ssize_t __pread64 (int __fd, void *__buf
{
__my_pthread_testcancel();
- return FORWARD(__pread64, __fd, __buf, __nbytes, __offset);
+ return FORWARD(__pread64, __libc_pread64, __fd, __buf, __nbytes, __offset);
}
@@ -2432,5 +2437,5 @@ ssize_t __pwrite64 (int __fd, const void
{
__my_pthread_testcancel();
- return FORWARD(__pwrite64, __fd, __buf, __nbytes, __offset);
+ return FORWARD(__pwrite64, __libc_pwrite64, __fd, __buf, __nbytes, __offset);
}
@@ -2442,5 +2447,5 @@ ssize_t pwrite(int fd, const void *buf,
{
__my_pthread_testcancel();
- return FORWARD(pwrite, fd, buf, count, offset);
+ return FORWARD(pwrite, __libc_pwrite, fd, buf, count, offset);
}
@@ -2452,5 +2457,5 @@ ssize_t pread(int fd, void *buf, size_t
{
__my_pthread_testcancel();
- return FORWARD(pread, fd, buf, count, offset);
+ return FORWARD(pread, __libc_pread, fd, buf, count, offset);
}
@@ -2461,5 +2466,5 @@ int recv(int s, void *msg, size_t len, i
{
__my_pthread_testcancel();
- return FORWARD(recv, s, msg, len, flags);
+ return FORWARD(recv, __libc_recv, s, msg, len, flags);
}
@@ -2470,5 +2475,5 @@ int send(int s, const void *msg, size_t
{
__my_pthread_testcancel();
- return FORWARD(send, s, msg, len, flags);
+ return FORWARD(send, __libc_send, s, msg, len, flags);
}
@@ -2480,5 +2485,5 @@ int sendmsg(int s, const struct msghdr *
{
__my_pthread_testcancel();
- return FORWARD(sendmsg, s, msg, flags);
+ return FORWARD(sendmsg, __libc_sendmsg, s, msg, flags);
}
@@ -2490,5 +2495,5 @@ int recvmsg(int s, struct msghdr *msg, i
{
__my_pthread_testcancel();
- return FORWARD(recvmsg, s, msg, flags);
+ return FORWARD(recvmsg, __libc_recvmsg, s, msg, flags);
}
@@ -2502,5 +2507,5 @@ int recvfrom(int s, void *buf, size_t le
{
__my_pthread_testcancel();
- return FORWARD(recvfrom, s, buf, len, flags, from, fromlen);
+ return FORWARD(recvfrom, __libc_recfrom, s, buf, len, flags, from, fromlen);
}
@@ -2514,5 +2519,5 @@ int sendto(int s, const void *msg, size_
{
__my_pthread_testcancel();
- return FORWARD(sendto, s, msg, len, flags, to, tolen);
+ return FORWARD(sendto, __libc_sendto, s, msg, len, flags, to, tolen);
}
@@ -2524,5 +2529,5 @@ int system(const char* str)
{
__my_pthread_testcancel();
- return FORWARD(system, str);
+ return FORWARD(system, __libc_system, str);
}
@@ -2534,5 +2539,5 @@ pid_t wait(int *status)
{
__my_pthread_testcancel();
- return FORWARD(wait, status);
+ return FORWARD(wait, __libc_wait, status);
}
@@ -2544,5 +2549,5 @@ int msync(const void *start, size_t leng
{
__my_pthread_testcancel();
- return FORWARD(msync, start, length, flags);
+ return FORWARD(msync, __libc_msync, start, length, flags);
}
@@ -2557,9 +2562,9 @@ strong_alias(write, __write)
strong_alias(connect, __connect)
strong_alias(send, __send)
+strong_alias(pause, __pause)
weak_alias (__pread64, pread64)
weak_alias (__pwrite64, pwrite64)
weak_alias(__nanosleep, nanosleep)
-weak_alias(__pause, pause)
weak_alias(__tcdrain, tcdrain)
@@ -2570,5 +2575,5 @@ void (*longjmp_t)(jmp_buf env, int val)
void longjmp(jmp_buf env, int val)
{
- FORWARD(longjmp, env, val);
+ FORWARD(longjmp, __libc_longjmp, env, val);
}
@@ -2579,5 +2584,5 @@ void siglongjmp(sigjmp_buf env, int val)
{
kludged("siglongjmp", "(it ignores cleanup handlers)");
- FORWARD(siglongjmp, env, val);
+ FORWARD(siglongjmp, __libc_siglongjmp, env, val);
}
@@ -2641,5 +2646,5 @@ pid_t __fork(void)
run_fork_handlers(0 /* prepare */);
- pid = FORWARD(__fork);
+ pid = FORWARD(__fork, __libc_fork);
if (pid == 0) {
/* I am the child */
|
|
From: Eric E. <eri...@fr...> - 2004-08-22 22:43:07
|
Tom Hughes wrote: > I have to say that I don't like --fmt=valgui as an option. > > The idea of a more machine readable output format is admirable, but > a more generalised name would be better I think. It may also be that > if the aim is for a machine readable output format you should go further > than just making the filenames absolute and go for something that is as > easy as possible for machines to parse. I completely agree, the option has been named to allow further extensions like --fmt=xxx where xxx could be anything else. (like txt for current 'short' format, html, xml, whatever people want). For now it was the shortest path, and I must confess that the complexity of parsing the output is one thing which has pained me a lot (and still does...). What I see as future requirements for output is: - typed output - extensible without needing to update the parsers - errors should contain attributes like severity - the parser must know immediately when an error block is finished - still permit to output using actual format (for other parsers) but of course this can't be done for 2.2.0 ! I would be glad to work on that, since it would greatly simplify my life :-) If you have a better name for that option, which suits every one, I can make update my patch against cvs head to reflect that. Cheers -- Eric PS: I thought you were an advocate of simple changes ;-) |
|
From: Tom H. <th...@cy...> - 2004-08-22 22:05:24
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So I propose create a new stable branch and release 2.2.0.
> I'd hope to do complete the process within a week.
>
> Comments?
>
> Are there any specific issues which should be addressed prior
> to 2.2.0 ?
There's one issue that definitely needs to be addressed, which is
bug #85658 which has come up dozens of times now - just look at the
number of duplicates that have been attached to it.
I've got a patch for it - an early version is on the bug. One or
two people still seem to have problems but in general the patch seems
to fix it for most people so I'll commit it shortly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-22 22:03:09
|
In message <412...@fr...>
Eric Estievenart <eri...@fr...> wrote:
> The issue is that it still requires a patched version of Valgrind,
> and it may trouble users.
> I would be glad if we could consider the current patch for inclusion:
> http://eric.estievenart.free.fr/tmp/vg212.diff
> Which fixes:
> - the dwarf2 reading (source file names were not absolute)
> - a more complete output when --fmt=valgui is given
> - log of program exit status (needed to know when children have exited)
I have to say that I don't like --fmt=valgui as an option.
The idea of a more machine readable output format is admirable, but
a more generalised name would be better I think. It may also be that
if the aim is for a machine readable output format you should go further
than just making the filenames absolute and go for something that is as
easy as possible for machines to parse.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Eric E. <eri...@fr...> - 2004-08-22 21:20:46
|
Julian Seward wrote: > So I propose create a new stable branch and release 2.2.0. > I'd hope to do complete the process within a week. > > Are there any specific issues which should be addressed prior > to 2.2.0 ? That's a good idea. I'm currently in active development mode on Valgui (yes, the obscure Qt frontend everybody may have thought was dead ;-). I expect to make an official pre-release within the next weeks, once I have finished the doc and fixed a few more bugs. The issue is that it still requires a patched version of Valgrind, and it may trouble users. I would be glad if we could consider the current patch for inclusion: http://eric.estievenart.free.fr/tmp/vg212.diff Which fixes: - the dwarf2 reading (source file names were not absolute) - a more complete output when --fmt=valgui is given - log of program exit status (needed to know when children have exited) I've used it intensively during the past months, and there seems to be no problem, but it is of course not to be added just one day before release, so a good week testing should be good. Any remarks welcome. Cheers -- Eric |
|
From: Julian S. <js...@ac...> - 2004-08-22 20:56:53
|
One of the major stumbling blocks to porting Valgrind is the lack of a CPU virtualisation framework. UCode has significant limitations, and rather than try and fix them, I think it better to abandon UCode, learn from it, and design something clean, and based on 1990s compiler technology -- UCode is rooted in the 60s. UCode's limitations, as I see them, are: * It's very tied to x86. The UInstrs are x86-specific, and there are x86-specific kludges, particularly the handling of condition codes. * Because the UInstrs are x86-specific, all the tools are exposed to architecture-specific details. Ports to other platforms (eg, experimental PPC port) introduce their own set of PPC-specific stuff. This leads to an N x M (archs x tools) maintenance headache. * It provides insufficient description of SIMD operations, hence memcheck et al cannot properly instrument them. This will become more of a problem as compilers more routinely generate SIMD code (and yes, even gcc is getting there). * It's microarchitecturally naive. UCode frequently and unavoidably swaps the %eflags state between the real and simulated CPUs. What we discovered too late is that this is an expensive operation on PII/III/4, Athlon -- costing between 10 and 20 cycles. The same problem also afflicts the FPU simulation. * It forces use of a naive, macro-expanding instruction selector which often generates poor code. Instruction selectors based on tree pattern matching ideas from the late 80s / early 90s are easy to implement and produce better code, but UCode precludes their use. * UCode hardwires the assumption that the guest and host CPU architectures are the same. It therefore rules out any future possibility of cross-architecture debugging, something which is important in the embedded arena. * UCode offers no support for optimisation across multiple basic blocks. Doing so could significantly improve performance. * The UCode machinery is deeply wired into the rest of Valgrind. This is a mistake: it makes it impossible to debug and profile the translator/instrumentors using a simple test driver. What I am thinking of is a framework based on an architecturally-neutral intermediate representation (IR). This IR will represent superblocks -- single entry, multiple exit regions of code, rather than the basic blocks we represent at present. The IR will fundamentally be a sequence of statements, and allow both flat SSA-style code, and arbitrarily deep expression trees, or any point in between, depending on what is convenient for the transformation next to be done. The IR will be strongly typed (machine-level types) and will have a clearly defined semantics. Those who have followed such discussions in the past will know that two alternative schemes have been proposed: * copy-annotate, in which original insns are copied more or less verbatim, and annotations supporting instrumentation are added * disassemble-resynthesise, in which original insns are unpicked into an intermediate representation, which is then instrumented, and real insns are then regenerated At present we use copy-annotate for FP/MMX/SSE/SSE2 instructions, and disassemble-resynthesise for the integer instruction set, excluding the condition code handling. This is an unholy mess. I am leaning towards a framework which is predominantly disassemble- resynthesise. I see that there are occasions where explicitly representing guest instruction semantics is infeasible, and so copy-annotate must be used for those. The framework will need to support that. However, I hope to keep that to a minimum. Currently I do not have anything much to show. I hope to come up with something more definite over the next couple of months. J |
|
From: Julian S. <js...@ac...> - 2004-08-22 20:55:50
|
Greetings all. Now seems like a good time to start a new 2.2.X branch, and emit 2.2.0. The reasons for doing so now are: * 2.0.0 is getting long in the tooth, yet people still tend to think of it as the use-by-default version, not unreasonably considering it is branded the 'stable' release. 2.1.2 is a big improvement on 2.0.0, yet many people won't get those improvements until they are released as 2.2.0. * There are some potentially destabilising changes coming up in the head, and it would be nice to ship something before then. So I propose create a new stable branch and release 2.2.0. I'd hope to do complete the process within a week. Comments? Are there any specific issues which should be addressed prior to 2.2.0 ? J |
|
From: Nicholas N. <nj...@ca...> - 2004-08-22 14:42:46
|
On Sun, 22 Aug 2004, Nicholas Nethercote wrote: >>> I haven't considered asm code at all here; some .S files need some >>> definitions, but you can't have any macros included in .S files. >> >> The opposite: you can't include anything *except* macros in .S files. >> They're passed through cpp, so macro expansion happens like in C. > > Whoops, yes, my bad. Also, in my original proposal, I said "definitions" repeatedly when I actually meant "declarations". Sorry for the confusion. I'll post a modified, more detailed proposal some time soon, in which I'll try to address the received comments. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-22 14:09:32
|
On Sat, 21 Aug 2004, Jeremy Fitzhardinge wrote: > My thinking also included a generic "unix" directory, for things which > are common to all unixes but not really inherent to the generic core of > Valgrind (eg, everyone has open/close/read/write, so you may as well > make them common). This would only really make sense if you start > porting to non-Unix-like targets (which is always an option, though the > most likely non-Unix target is Windows, which looks pretty formidable). I'd say let's do that if/when the need arises. >> Abstract directory structure: >> >> valgrind/ >> >> coregrind/ >> >> arch/ >> >> arch_common_defs.h (contains arch-specific definitions) >> common_os_defs.h (contains OS-specific definitions) >> arch_os_defs.h (contains platform-specific definitions) > > Are these common across all arch/os combinations? How can they be > specific? Or do you mean $ARCH_common_defs.h? They're meant to be common. Things like the function definition for VG_(load_thread_state)(). >> $ARCH-$OS/ >> >> arch_os_macros.h (contains platform-specific macros used by core) >> arch_os.a (contains all platform-specific code) > > Is the source which generates the .a files also in these directories? Yes. >> The generic part would need only these six #includes: >> >> #include "platform/arch_common_defs.h" >> #include "platform/common_os_defs.h" >> #include "platform/arch_os_defs.h" >> >> These could be put in vg_include.h and thus be made visible to all core >> code. Or not. > > Why not make it that the generic code always includes arch_os_defs.h, > which in turn can include whichever generic headers are appropriate. > This allows for things which are common across some arch/os combinations > but not all (ELF loader, for example). Sure, could do; that seems like a more minor point to me. > The general idea is to allow arch-os ports to use generic code if > appropriate, but they can always provide their own versions if necessary > (ie, generic code is an arch-os helper library rather than something > they're forced to use). Obviously use of generic code should be > strongly encouraged, and rather than using an arch-os specific version > of a generic function, we would prefer to make the generic code more > generic. We may have different views of what is meant by "generic". I view normal operation as mostly occurring within generic code, but occasionally having to do something arch/os/platform specific, eg. get the stack pointer, or run a syscall -- in which case the generic code calls code in the arch/os/platform part. It sounds like you're thinking of generic code as a kind of library that the arch/os/platform-specific code can call upon to help its needs. Is that right? Perhaps both views are necessary. > In general I'm not terribly keen on symlinks; why couldn't you set the > linker search path with make variables? You could. Symlinks vs. specifying-include-dirs seems to be a style issue; Paul prefers symlinks, you and Bob prefer includes. It doesn't matter that much. >> Note that arch/ is a really bad name. I'm not convinced we even need that >> subdirectory between coregrind/ and the non-generic subdirs -- it will >> just create more typing, for little benefit. > > I don't think that's a big issue, and I'd prefer to be able to "ls arch" > to see what we have there. Then we're in disagreement. >> I haven't considered asm code at all here; some .S files need some >> definitions, but you can't have any macros included in .S files. > > The opposite: you can't include anything *except* macros in .S files. > They're passed through cpp, so macro expansion happens like in C. Whoops, yes, my bad. >> 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. > > I'd prefer the "common", or something like it, so you can match, say, > all x86 files with x86-* or *-linux (in other words, consistency for > automated name generation is more important). Then we're in disagreement again. N |
|
From: Tom H. <th...@cy...> - 2004-08-22 03:06:28
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-22 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow badfree: valgrind -q ./badfree badjump: valgrind ./badjump badloop: valgrind -q ./badloop badrw: valgrind -q ./badrw brk: valgrind ./brk buflen_check: valgrind -q ./buflen_check clientperm: valgrind -q ./clientperm 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 Could not read `inits.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-22 02:55:47
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-22 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-22 02:25:37
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-22 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-22 02:19:26
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-22 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-22 02:13:15
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-22 03:10:01 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-22 02:08:36
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-22 03:05:04 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: Bob F. <bfr...@si...> - 2004-08-22 01:11:39
|
On Sat, 21 Aug 2004, Jeremy Fitzhardinge wrote: > >> 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. > > GNU make is much better documented and more tractable than the teetering > pile of M4, perl, sh and Makefiles, and the reliance on their > overlapping syntax. Comparing GNU make to Automake is almost like comparing an assembly language with a compiled language. It is easy enough to get started with GNU make for small programs, but building serious projects with the expected bells and whistles takes considerable effort just to get the framework in place. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Jeremy F. <je...@go...> - 2004-08-22 00:50:52
|
On Sat, 2004-08-21 at 13:42 -0500, Bob Friesenhahn wrote:
> 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.
>
Of these:
> Provides:
>
> * Provides a solid 'dist' target.
> * Provides a self-validating 'distcheck' target.
> * Works well with VPATH builds.
I think these are the really useful ones.
> Does not provide:
>
> * Makefile includes.
> * Wildcarded sources/targets.
> * GNU make style functions.
> * Run-time make conditionals (uses configure time conditionals).
And these are all big minuses. I would add:
* huge complexity
* bad documentation
* inflexible (or perhaps that's only "apparently inflexible, given
the bad documentation)
* multistage build just to generate Makefiles (I hate the fact
that you can't just edit the Makefiles and use them without a
"compilation" stage)
* billions of subtly incompatible versions
> 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.
GNU make is much better documented and more tractable than the teetering
pile of M4, perl, sh and Makefiles, and the reliance on their
overlapping syntax.
So, I'd happily drop both automake and autoconf and do something more
kernel-like.
J
|
|
From: Jeremy F. <je...@go...> - 2004-08-22 00:36:32
|
On Fri, 2004-08-20 at 12:47 +0100, Nicholas Nethercote wrote: > 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". > > 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 Yep. This all looks pretty sound. My thinking also included a generic "unix" directory, for things which are common to all unixes but not really inherent to the generic core of Valgrind (eg, everyone has open/close/read/write, so you may as well make them common). This would only really make sense if you start porting to non-Unix-like targets (which is always an option, though the most likely non-Unix target is Windows, which looks pretty formidable). > > Abstract directory structure: > > valgrind/ > > coregrind/ > > arch/ > > arch_common_defs.h (contains arch-specific definitions) > common_os_defs.h (contains OS-specific definitions) > arch_os_defs.h (contains platform-specific definitions) Are these common across all arch/os combinations? How can they be specific? Or do you mean $ARCH_common_defs.h? > arch_common@ (symlink to $ARCH-common/, made at config-time) > common_os@ (symlink to common-$OS/, made at config-time) > arch_os@ (symlink to $ARCH-$OS/, made at config-time) > > $ARCH-common/ > > arch_common_macros.h (contains arch-specific macros used by core) > arch_common.a (contains all arch-specific code) > > common-$OS/ > > common_os_macros.h (contains OS-specific macros used by core) > common_os.a (contains all OS-specific code) > > $ARCH-$OS/ > > arch_os_macros.h (contains platform-specific macros used by core) > arch_os.a (contains all platform-specific code) Is the source which generates the .a files also in these directories? > The generic part would need only these six #includes: > > #include "platform/arch_common_defs.h" > #include "platform/common_os_defs.h" > #include "platform/arch_os_defs.h" > > These could be put in vg_include.h and thus be made visible to all core > code. Or not. Why not make it that the generic code always includes arch_os_defs.h, which in turn can include whichever generic headers are appropriate. This allows for things which are common across some arch/os combinations but not all (ELF loader, for example). The general idea is to allow arch-os ports to use generic code if appropriate, but they can always provide their own versions if necessary (ie, generic code is an arch-os helper library rather than something they're forced to use). Obviously use of generic code should be strongly encouraged, and rather than using an arch-os specific version of a generic function, we would prefer to make the generic code more generic. > > Each of the _defs.h files would have the following respective #includes: > > #include "platform/arch_common/arch_common_macros.h" > #include "platform/common_os/common_os_macros.h" > #include "platform/arch_os/arch_os_macros.h" > > in order to pull in the relevant _macros.h files -- the symlinks would > ensure the right ones are pulled in. > > When building stage2, coregrind/Makefile.am would just link all the core > modules with: > > - platform/arch_common/arch_common.a > - platform/common_os/common_os.a > - platform/arch_os/arch_os.a > > The symlinks would again ensure this works. These .a files would be made > by linking together all the .o files in each part. In general I'm not terribly keen on symlinks; why couldn't you set the linker search path with make variables? > Each non-generic sub-dir can also include as many other .c, .h and .S > files as it needs (plus anything else, like ld scripts). But the generic > part wouldn't see or care about that. > > > Note that arch/ is a really bad name. I'm not convinced we even need that > subdirectory between coregrind/ and the non-generic subdirs -- it will > just create more typing, for little benefit. I don't think that's a big issue, and I'd prefer to be able to "ls arch" to see what we have there. > I haven't considered skins at all here. Perhaps each of the the proposed > headers needs to be split into two halves: one for the skin-visible > stuff, and one for the core-visible stuff (which would #include the > skin-visible header). Yep. > I haven't considered asm code at all here; some .S files need some > definitions, but you can't have any macros included in .S files. The opposite: you can't include anything *except* macros in .S files. They're passed through cpp, so macro expansion happens like in C. > I haven't considered the UME stuff that is shared between stage1 and > stage2. Not sure about that, it would probably be kept separate at least > to some extent. The only issue is whether it gets compiled once or twice. I think it should be possible to compile once and link the .so into both executables. > > For tools that need to do non-generic things (which should be avoided as > much as possible, but may be inevitable in small amounts, esp. for > Memcheck) parts of the structure can be mirrored as necessary within the > tool/ (eg. memcheck/) directory. > > 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. I'd prefer the "common", or something like it, so you can match, say, all x86 files with x86-* or *-linux (in other words, consistency for automated name generation is more important). > - 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. Well, we're hoping to disappear that altogether... J |