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
(1) |
2
|
|
3
|
4
|
5
(2) |
6
(3) |
7
|
8
(2) |
9
(3) |
|
10
(3) |
11
(5) |
12
(1) |
13
|
14
(21) |
15
(6) |
16
(4) |
|
17
(9) |
18
(13) |
19
(15) |
20
(15) |
21
(11) |
22
(16) |
23
(4) |
|
24
|
25
(8) |
26
(4) |
27
(3) |
28
(1) |
29
|
30
(2) |
|
From: Carlo W. <ca...@al...> - 2002-11-15 23:26:36
|
On Fri, Nov 15, 2002 at 09:02:35PM +0100, Josef Weidendorfer wrote: > By mistake, loading of weak symbols was commented out in valgrinds symbol > loader (BAD BUG !!). > I checked out libecc and did a testrun. > In fact, I have not a single "0x..." or "???" here at all. Hmm, I did (for a library without any debugging symbols?) kcachegrind gave me: 0x404ACCA4 libcwd.so.99.26:stl_map.h This is nonsense: stl_map.h is not a header file of libcwd and 0x404ACCA4 has no debugging symbols, so it can't (known to) be in to stl_map.h (actually, I can't figure out to which library it belows to at all: without cachegrind running, there is no library loaded at all at that address; and neither is there while cachegrind is running). I tried also to put a break point at that address with gdb, but it never comes there. Weird that it shows up in the output of cachegrind. -- Carlo Wood <ca...@al...> |
|
From: Julian S. <js...@ac...> - 2002-11-15 23:00:22
|
On Friday 15 November 2002 10:49 pm, Carlo Wood wrote: > On Fri, Nov 15, 2002 at 03:31:51PM +0100, Josef Weidendorfer wrote: > > Hi Carlo, > > > > can you forward this to "val...@li...", too? > > You can subscribe to the list. > > > > I'm VERY pleased you have a good symbol loader. > > Perhaps we can merge the good bits. We have some problems with demangling > > symbols starting with "GLOBAL_" (GCC 3.2)... > > > > I've you are using templates: Yes, these functions all get weak symbols. > > And won't be read in by valgrind 1.0.4. This should be solved with > > 1.0.5/1.2.0. You can get valgrind HEAD at sourgeforge, anonymous CVS, > > project is named "valgrind". > > I tried the HEAD CVS, and get this: > >cachegrind testPolynomial The way to run this in the head has changed. I think you need to do $prefix/valgrind --skin=cachegrind testPolynomial Head works fine for me right now. J |
|
From: Carlo W. <ca...@al...> - 2002-11-15 22:50:48
|
On Fri, Nov 15, 2002 at 03:31:51PM +0100, Josef Weidendorfer wrote: > Hi Carlo, > > can you forward this to "val...@li...", too? > You can subscribe to the list. > > I'm VERY pleased you have a good symbol loader. > Perhaps we can merge the good bits. We have some problems with demangling > symbols starting with "GLOBAL_" (GCC 3.2)... > > I've you are using templates: Yes, these functions all get weak symbols. And > won't be read in by valgrind 1.0.4. This should be solved with 1.0.5/1.2.0. > You can get valgrind HEAD at sourgeforge, anonymous CVS, project is named > "valgrind". I tried the HEAD CVS, and get this: >cachegrind testPolynomial testPolynomial: relocation error: /usr/local/lib/valgrind/valgrind.so: undefined symbol: vgPlain_skin_interface_major_version Am I doing something wrong? Or is the HEAD broken? -- Carlo Wood <ca...@al...> |
|
From: Jeremy F. <je...@go...> - 2002-11-15 20:58:31
|
Ahem. Ctrl-enter is send, not line break. Anyway... On Fri, 2002-11-15 at 12:32, Jeremy Fitzhardinge wrote: > > It contains > > a lot of details about translation chaining, a simple-ish change > > [compared to the above] which would save about 15 (real-machine) insns > > per basic block executed. > 2 > > Anyway, I was thinking about chaining, and it doesn't look too hard > (meaning, I couldn't think of any completely insoluble problems). > My thinking was something like: 1. for each normal jump (jump rather than call, syscall, etc; also static rather than computed or indirect target address) out of a basic block, you'd generate code which looks something like: movl $next_bb_addr, %eax decl bbcount jnz 1f # unless x86 has conditional ret ret # normal path 1: call codegen # generate code at %eax nop; nop # nops, if we need space for the jmp 2. the clever bit is that codegen generates the target code and then back-patches its own call site into a jmp to the generated code. If you still want to be able to move generated code around (still don't quite understand that), then it could be an indirect jump via some stable place. codegen() would then jump to the newly generated code. 3. each entry in the translation table would list the set (max of 2 jumps per basic block?) of chained basic blocks. Cleaning up the translation table would have a mark/sweep pass first, so we don't clear out any code which is being chained to. Or we could re-patch the jump into a call to codegen. It might also be possible to keep emulated registers in real registers for longer, but I haven't thought about the details yet (well, I have, and it just kept getting more complex the more I thought about it, so its probably a bad idea). I should really read the Shade paper again. I skimmed it this morning, so the stuff above is just me getting distracted and going off on a tangent rather than something informed by the paper. J |
|
From: Jeremy F. <je...@go...> - 2002-11-15 20:32:31
|
On Fri, 2002-11-15 at 00:32, Julian Seward wrote: > > What are the problems which prevent recursive execution? Dynamic > > codegen is going to be tricky, obviously, and I guess the dynamic linker > > hackery might get tricky. Even if V could only run a limited subset of > > programs when self-virtualized, it would help a lot. It seems so > > strange that we're restricted to primitive tools for use within the > > sophisticated tool... > > Well, now you got me thinking. I think you're into a research-grade > question there. Here FWIW is a suggestion. > > Part of the weakness of the existing V infrastructure is that we depend > on the existing dynamic linker and are accumulating a lot of hacks to > cope with that. > > It would be nice if valgrind was "just another" bog-standard C or C++ > program; no LD_PRELOAD hackery, no annoying restriction on the use of > libc functions or other libraries internally. I've been thinking along similar lines, though mostly while doing thought experiments in making Valgrind do cross-simulation (though it looks like bintrans is already on that path). > This could be achieved if V loaded and linked the executable to run, > itself. Rather than write our own complete ELF loader/linker, if we > ask really nicely (Mark? pretty please) we could "borrow" that machinery > from Mark's "bintrans" (http://www.complang.tuwien.ac.at/schani/bintrans). Well, a user-mode exec is reasonably easy - I've done that before. And stolen bits of a dynamic linker should be pretty easy to glue in (and bintrans does look like an interesting organ donor). > > Disadvantages are > > 1. is it's yet more code to maintain in the codebase. > > 2. we'd have to be very careful to intercept all dlopen-style calls > and do the right emulation. At the moment we ignore them because > ld.so or whatever it is sorts it all out for us even when running > on the simulated CPU. Really? If we do a full process emulation, then we take control before ever running the first target instruction. It doesn't matter if the target code is statically linked, dynamically linked or does its own code loading. All we need to be carful about is managing the generated code cache. We could still set LD_PRELOAD/LD_LIBRARY_PATH for the target process to influence its choice of libraries, so we can still intercept interesting library functions and do pthreads emulation. There's the interesting question of how to manage the address space, though I suppose the current scheme would work OK (certainly if V reserves a chunk of the user virtual address space for itself, and makes sure the target process doesn't intrude). On the other hand, if the target process lives in its own address space then we don't need to worry about conflicts at all; but this would probably need a software-emulated address translation mechanism, which might be a bit of a performance hit (unless we can do something clever with mmap/mremap to get the hardware to do the work). > 3. related to 2, it becomes possible to envisage using a higher-level > language like C++ (no laughing please) to reconstruct the core dynamic > translation, instrumentation, optimisation machinery. If you are > interested in serious performance improvements, the core translation > machinery will probably have to work across multiple basic blocks > (for example, detect loops and do better on them) and doing more > sophisticated stuff would probably be less painful in C++ or OCaml > or something. It would be nice to have some higher level tools to work with. C++ would be an OK match for the current machinery, and it would be interesting to see what you could do with something like OCaml. I think doing more complex global analysis is going to be hard regardless of the tools you use, because one of V's advantages is working on arbitrary machine code, which may not have any useful structure to take advantage of (what I mean is that any performance advantage of doing global analysis may be overwhelmed by all the checking needed to make sure the assumptions are still valid). > 5. [minor point] V could itself be multithreaded, which might help > our thread library simulation -- could make a thread to do asynch IO > (am thinking of your recent comments re 03a-open patch). Yep. > For more immediate performance stuff I strongly suggest you read > "Shade: A Fast Instruction-Set Simulator for Execution Profiling" > (http://www.cs.washington.edu/research/compiler/papers.d/shade.html) > which is the most direct technical influence on valgrind. It contains > a lot of details about translation chaining, a simple-ish change > [compared to the above] which would save about 15 (real-machine) insns > per basic block executed. Ah, Shade! I spend quite a bit of time reading that paper when it appeared. I was working on Byron Rakitzis's implementation of pico (the image processing language) which did dynamic codegen for Sparc. I was going to write a short description, but the 2nd Google hit is a comp.compilers posting of mine describing it: http://compilers.iecc.com/comparch/article/93-04-102 Anyway, I was thinking about chaining, and it doesn't look too hard (meaning, I couldn't think of any completely insoluble problems). My thinking was something like: 1. for each jump out of a basic block, you'd generate code which looks something like: J |
|
From: Julian S. <js...@ac...> - 2002-11-15 08:25:42
|
[Hi Mark! How's it going? -- J] > > > BTW, will Valgrind run on itself? > > > > No way, Hos/e! Shame; it would be nice to clean up v's memory management > > ... > > I've been carving out chunks and running them in standalone test > programs so I can run them under V, but I've got to the point where I > have dependencies on the actual execution context, and I'm not sure if I > want to try and simulate that standalone... > > What are the problems which prevent recursive execution? Dynamic > codegen is going to be tricky, obviously, and I guess the dynamic linker > hackery might get tricky. Even if V could only run a limited subset of > programs when self-virtualized, it would help a lot. It seems so > strange that we're restricted to primitive tools for use within the > sophisticated tool... Well, now you got me thinking. I think you're into a research-grade question there. Here FWIW is a suggestion. Part of the weakness of the existing V infrastructure is that we depend on the existing dynamic linker and are accumulating a lot of hacks to cope with that. It would be nice if valgrind was "just another" bog-standard C or C++ program; no LD_PRELOAD hackery, no annoying restriction on the use of libc functions or other libraries internally. This could be achieved if V loaded and linked the executable to run, itself. Rather than write our own complete ELF loader/linker, if we ask really nicely (Mark? pretty please) we could "borrow" that machinery from Mark's "bintrans" (http://www.complang.tuwien.ac.at/schani/bintrans). Disadvantages are 1. is it's yet more code to maintain in the codebase. 2. we'd have to be very careful to intercept all dlopen-style calls and do the right emulation. At the moment we ignore them because ld.so or whatever it is sorts it all out for us even when running on the simulated CPU. Advantages are 1. we now have 100% control over the loading/linking process 2. we can use whatever libraries we want in building valgrind; no more mylibc.c 3. related to 2, it becomes possible to envisage using a higher-level language like C++ (no laughing please) to reconstruct the core dynamic translation, instrumentation, optimisation machinery. If you are interested in serious performance improvements, the core translation machinery will probably have to work across multiple basic blocks (for example, detect loops and do better on them) and doing more sophisticated stuff would probably be less painful in C++ or OCaml or something. 4. [to answer your question, finally] it would make valgrind a peer of the programs it runs. Meaning: V would become just-another bog-standard linux executable which runs bog-standard linux executables, and so its chances of self-hosting IMO would be much improved. Currently it is shell script and bunch of .so's which get tacked onto the side of running programs, and so is not really a peer of them. 5. [minor point] V could itself be multithreaded, which might help our thread library simulation -- could make a thread to do asynch IO (am thinking of your recent comments re 03a-open patch). The self-modifying code is not a big deal. If we want this can be transparently supported by checking all writes and invalidating TT/TC as needed. Very old V snapshots (pre Jan 2002) had this and it "just worked" (tm). There is [was?] even a program in the test suite to test it. For more immediate performance stuff I strongly suggest you read "Shade: A Fast Instruction-Set Simulator for Execution Profiling" (http://www.cs.washington.edu/research/compiler/papers.d/shade.html) which is the most direct technical influence on valgrind. It contains a lot of details about translation chaining, a simple-ish change [compared to the above] which would save about 15 (real-machine) insns per basic block executed. J |