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
(9) |
2
(13) |
3
(3) |
4
(3) |
5
(4) |
|
6
(2) |
7
(4) |
8
(3) |
9
(2) |
10
|
11
|
12
(6) |
|
13
(6) |
14
(1) |
15
(2) |
16
(2) |
17
(2) |
18
|
19
|
|
20
|
21
|
22
(1) |
23
|
24
(2) |
25
(5) |
26
|
|
27
(1) |
28
(8) |
29
(3) |
30
|
|
|
|
|
From: Adam G. <ar...@cy...> - 2003-04-08 10:56:15
|
At 03:00 08/04/03 -0700, Jeremy Fitzhardinge wrote: >Quoting Julian Seward <js...@ac...>: > >> >> I've spent the afternoon messing with R H 9. Graydon and Jeff have >> done a great job telling me useful stuff for getting V to work on >> RH9, and thanks to them for that. >> >> So it sort-of works. Unfortunately OpenOffice hangs, due to an >> accept() >> call which isn't correctly routed to V's only-this-thread-blocks >> implementation thereof, and so the whole app hangs. Sigh. I think it >> might be due to ld.so in 9 ignoring -z initfirst. > >At least one possible problem is that if two things have initfirst - well, they >can't both be first. > >> It's all a swamp, and V is getting more and more cluttered with stuff >> to work around this kind of problem. JeremyF's vg_intercept.c thing >> is the latest addition. > >And it is well ugh-worthy. > >> 1. We can't really simulate the native posix threading libraries; > >What do you mean by "simulate"? Do you mean we can emulate the presence of the >library, but we can't run a simulation of the actual library? > >What we could do is move Valgrind's thread simulation an abstraction level down, >and intercept the clone system call, and then run the "real" thread library on >that. Unfortunately that loses the higher-level insight Valgrind gets into the >threading behaviour of the target program. clone() implementation patch available on request... ;-) this is exactly what I did for valgrind's WINE support. there are several problems with implementing clone() using 'green' threads - the biggest one is that external processes cannot send signals to the new threads (it's causing major headaches trying to get patches into WINE to cope with this). if you want to REALLY clone a new thread, then you'll have to add all sorts of locking to valgrind to cope with it - I had a look at this but it appears to be a big job. currently valgrind itself is pretty much single threaded - with real cloned threads that won't be the case. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-08 10:34:02
|
Hi, I just added a Makefile target for running the regression tests. Use "make regtest" to run them now. This is slightly easier than the old '$PREFIX/bin/vg_regtest --all'. If anyone ever wants to add some regression tests, feel free. If you are unsure about how the script works, you can send me the test program along with the expected normal output and Valgrind output and I'll add it. N |
|
From: Jeremy F. <je...@go...> - 2003-04-08 10:00:46
|
Quoting Julian Seward <js...@ac...>: > > I've spent the afternoon messing with R H 9. Graydon and Jeff have > done a great job telling me useful stuff for getting V to work on > RH9, and thanks to them for that. > > So it sort-of works. Unfortunately OpenOffice hangs, due to an > accept() > call which isn't correctly routed to V's only-this-thread-blocks > implementation thereof, and so the whole app hangs. Sigh. I think it > might be due to ld.so in 9 ignoring -z initfirst. At least one possible problem is that if two things have initfirst - well, they can't both be first. > It's all a swamp, and V is getting more and more cluttered with stuff > to work around this kind of problem. JeremyF's vg_intercept.c thing > is the latest addition. And it is well ugh-worthy. > 1. We can't really simulate the native posix threading libraries; What do you mean by "simulate"? Do you mean we can emulate the presence of the library, but we can't run a simulation of the actual library? What we could do is move Valgrind's thread simulation an abstraction level down, and intercept the clone system call, and then run the "real" thread library on that. Unfortunately that loses the higher-level insight Valgrind gets into the threading behaviour of the target program. > What I am thinking of is this: > > A. Turn V into a bog-standard program, not an LD_PRELOAD thing, > which contains its own ELF loader. This makes (3) go away, and > it gives us complete control of (2). ELF loaders exist; > we might be able to start from Mark Probst's loader in bintrans > if we ask nicely :-) > (http://www.complang.tuwien.ac.at/schani) ELF loaders are easy. There are some complexities though: does Valgrind live in the same address space as the target app, or a separate one? If its the same one, then you get the problem of making two libc's exist in the same address space. If they're in different address spaces, you have the question of how to give Valgrind efficient control of the target address space (which ideally requires OS support in the form of an address space without its own thread - something pretty alien to Linux's model of things). The third option is the compromise: make them logically distinct address spaces, but have them share the same actual address space by adding another virtualization layer on address translation. > B. Now that we have complete control over loading, we can reliably > substitute in our own libpthread.so. Whoa there - you're leaping to conclusions. A implies you have an ELF loader which emulates execve() - ie, user-space exec. But it doesn't necessarily mean you've replaced ld.so and its loading mechanisms (which was already all in user- space). If you do mean replacing ld.so and its resolution mechanism, it means you're willing to actually understand how all that stuff works and 1) emulate it while 2) modifying the behaviour for our purposes. However, I think once you've done 1) you can probably get the existing dynamic linker to do what we need. User-space exec does make it easy to replace ld.so with anything we like, because we can choose to mis-interpret the ET_INTERP program header. > Now, we are going to have to jump through hoops to come up with > another libpthread.so which works properly with NPTL. So > (and this is where you need your barfbags) how about also ignoring > requests to load glibc.so. Instead, we supply our own > implementation > of libc, which probably also contains our integrated pthreads > implementation. If you're actually proposing that we replace glibc with an ABI-compatible re- implementation which happens to not use NPTL, then I think that's a huge amount of work with a lot of disadvantages. We could just package an appropriately built glibc with valgrind itself and use that, but that may still cause more problems than it solves. I think it would help me if someone could explain exactly how NPTL differs from normal pthreads at the ABI level. Why does Valgrind care? What changes are made to the instruction stream? > Um, I don't know if this is a really really stupid idea or not. > Probably is. Please feel free to shoot me down in flames. > (be as rude as you like :) > > It would be nice (in the long run) for V to be more modular. It's > pretty clear that the virtual CPU can be made fairly modular -- > basically, made into a library which translates a source bb into an > instrumented bb. Being modular helps if we want to think about making > a virtual CPU for some other architecture. I definitely agree. The trouble is that V really wants to operate of several levels of abstraction at once. At core it is a CPU/OS syscall emulator, and at that level this proposal makes some sense. However, because Valgrind also does emulation at the library level, it wants to be at the next level up. I think we can probably address this in two parts: 1. make V a full stand-alone CPU/syscall emulator, which is capable of running most programs (even threaded) without having to do any library intercepts, simply by emulating enough of the syscall layer for pthreads to work. 2. Some skins really want to understand what's happening at the library call level rather than the syscall leveL (helgrind, for example, wants to know where and what a lock is). In that case, library intercepts are the only option. We can either do this at the dynamic linker level (ie, what V does now), or perhaps at the CPU level (if you see a call to this address, quietly redirect it through this function). This means that we can avoid all the current complexity. All we need to do is look up the address of pthread_mutex_lock (say), and add that address to an intercept table which the dynamic codegen can consult whenever it is about to generate some code. That intercept table would list a pair of "run before"/"run after" functions which would be inserted into the generated code. J |