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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Chris J. <ch...@at...> - 2005-01-09 14:40:56
|
> On Sat, 2005-01-08 at 20:20 +0000, Chris January wrote: > > > Yep, that would be nice to have. Do you have any more > > > concrete thoughts? It seems like a difficult problem,=20 > > > because there's nothing generic about a Tool; they can get=20 > > > very special purpose. How does one represent that on the=20 > > > wire, and how can a generic debugger deal with it once its there? > >=20 > > Tools would publish their own API helper libraries. These would=20 > > interpret the data stored in the tool specific area of the shared=20 > > memory region. A client could ask the API what information the tool=20 > > provided. A client would either request this information as=20 > a binary=20 > > structure, which it would then need to interpret, or could=20 > ask for it=20 > > in string form in which case it would be displayed=20 > unprocessed to the=20 > > user. > >=20 > > >=20 > > > > The only problem with the original shared memory implementation=20 > > > > was > > > > the exposure of internal data structures. To solve this=20 > problem I=20 > > > > propose adding a debugging API shared library to Valgrind. This=20 > > > > library would be released as part of the Valgrind package and=20 > > > > installed at the same time. The library could therefore=20 > freely use=20 > > > > access internal data structures without any problems.=20 > > > Valgrind's core > > > > would expose useful debugging information, such as=20 > registers, and > > > > debugging control variables such as single stepping=20 > through shared=20 > > > > memory as before (either SysV or mmap). > > >=20 > > > (I don't think shared memory would be a good idea. It would > > > preclude remote machine access, and adds a complex protocol=20 > > > overhead for synchronizing between the debugger and the=20 > > > Valgrind threads.) > >=20 > > It's not difficult to synchronise between the debugger and Valgrind=20 > > threads. That is to say, I encountered no problems=20 > implementing this. >=20 > Well, I've just rearranged the internals again which affects=20 > the thread structure. Sure, the basic debugging pattern will=20 > be "stop the world; inspect modify state; resume the world",=20 > so there isn't much concurrency, but I don't understand what=20 > advantage using shared memory offers. You can't inspect or modify the state of the inferior process easily if = it's running under Valgrind because the register sets are not stored in = kernel space, they are stored at an unknown location in the inferior process. Shared memory effectively gives you a known location to look for the register sets and other information.=20 > Also, now that Valgrind can self-virtualize, you need to be=20 > able to deal with multiple Valgrind instances within one=20 > process, and be able to distinguish them. I don't think this is really necessary and GDB doesn't support this kind = of architecture anyway. >=20 > > The advantage of the debugging API is you can implement the GDB=20 > > protocol atop of it (e.g. for remote debugging or to=20 > support debuggers=20 > > without a Valgrind target), but you are not limited to it. It also=20 > > means the GDB server can be a separate component, whereas=20 > without the=20 > > API it would be more closely coupled to the Valgrind core. >=20 > What about the other way around? Is the gdb protocol=20 > completely inextensible? It's inextensible in the sense that any extension would require changes = to GDB which is what we were trying to avoid in the first place. >=20 > I think the internal interface to any debugging protocol=20 > driver will be pretty simple anyway, so there's no particular=20 > advantage to deep layering. All it needs to be able to do is=20 > to be able to drive some async IO and inspect/modify memory=20 > and the ThreadState structures. Shared memory would make it=20 > more complex by adding more state to manage. Shared memory actually reduces the amount of state to manage because you don't have to worry about the inferior process at all - all interaction = is with the shared memory region. Chris |
|
From: Nicholas N. <nj...@ca...> - 2005-01-09 11:27:07
|
On Sat, 8 Jan 2005, Jeremy Fitzhardinge wrote: > One other thing we could look at is reviving Nick's interactive mode > stuff. I'm guessing it has aged rather a lot. Yes. I don't think it was the right way to go, because it duplicated a lot of the GDB stuff anyway. All I really wanted was to be able to call a tool-specified C function from within GDB, but when I tried just doing that I had various problems; sometimes it would work and sometimes it would seg fault. I vaguely remember hearing that GDB's support for such C calls was flaky, but maybe Valgrind's interactions were causing other problems. N |
|
From: <js...@ac...> - 2005-01-09 03:56:56
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-09 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 188 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-09 03:24:22
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-09 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 15359 Illegal instruction VALGRINDLIB=/tmp/valgrind.31670/valgrind/.in_place /tmp/valgrind.31670/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-09 03:20:26
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-09 03:15:08 GMT 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 -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-09 03:14:14
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-09 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-09 03:08:38
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-09 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-09 03:04:01
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-09 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-09 00:15:27
|
On Sat, 2005-01-08 at 20:20 +0000, Chris January wrote: > > Yep, that would be nice to have. Do you have any more > > concrete thoughts? It seems like a difficult problem, > > because there's nothing generic about a Tool; they can get > > very special purpose. How does one represent that on the > > wire, and how can a generic debugger deal with it once its there? > > Tools would publish their own API helper libraries. These would interpret > the data stored in the tool specific area of the shared memory region. A > client could ask the API what information the tool provided. A client would > either request this information as a binary structure, which it would then > need to interpret, or could ask for it in string form in which case it would > be displayed unprocessed to the user. > > > > > > The only problem with the original shared memory implementation was > > > the exposure of internal data structures. To solve this problem I > > > propose adding a debugging API shared library to Valgrind. This > > > library would be released as part of the Valgrind package and > > > installed at the same time. The library could therefore freely use > > > access internal data structures without any problems. > > Valgrind's core > > > would expose useful debugging information, such as registers, and > > > debugging control variables such as single stepping through shared > > > memory as before (either SysV or mmap). > > > > (I don't think shared memory would be a good idea. It would > > preclude remote machine access, and adds a complex protocol > > overhead for synchronizing between the debugger and the > > Valgrind threads.) > > It's not difficult to synchronise between the debugger and Valgrind threads. > That is to say, I encountered no problems implementing this. Well, I've just rearranged the internals again which affects the thread structure. Sure, the basic debugging pattern will be "stop the world; inspect modify state; resume the world", so there isn't much concurrency, but I don't understand what advantage using shared memory offers. Also, now that Valgrind can self-virtualize, you need to be able to deal with multiple Valgrind instances within one process, and be able to distinguish them. > The advantage of the debugging API is you can implement the GDB protocol > atop of it (e.g. for remote debugging or to support debuggers without a > Valgrind target), but you are not limited to it. It also means the GDB > server can be a separate component, whereas without the API it would be more > closely coupled to the Valgrind core. What about the other way around? Is the gdb protocol completely inextensible? I think the internal interface to any debugging protocol driver will be pretty simple anyway, so there's no particular advantage to deep layering. All it needs to be able to do is to be able to drive some async IO and inspect/modify memory and the ThreadState structures. Shared memory would make it more complex by adding more state to manage. J |
|
From: Chris J. <ch...@at...> - 2005-01-08 20:19:36
|
> On Sat, 2005-01-08 at 16:56 +0000, Chris January wrote: > > This seemed like > > the 'right' solution at the time because GDB didn't need to have=20 > > special knowledge about Valgrind (or so I thought) and I began=20 > > implementing it but didn't have enough time to finish. >=20 > How far did you get? I don't remember exactly - it was a number of months ago. >=20 > > However now I am revisiting the problem > > and have concluded that this idea is not the best solution because: > > a) it is limited to debuggers implenting the GDB remote debugging=20 > > protocol. >=20 > I'm not terribly worried about that, especially since the set=20 > of debuggers implementing the gdb protocol is vastly larger=20 > than the set using a special Valgrind library. True. >=20 > > b) it still needs a specialised Valgrind target for GDB to launch=20 > > Valgrind and connect to the server port in one operation.=20 > (I suppose=20 > > it would be feasible to have the user manually launch Valgrind and=20 > > then have Valgrind wait for GDB to connect but this is less than=20 > > ideal.) >=20 > Valgrind could do that itself, if that were a major concern. =20 > One of the nice things about having gdb separate is that its=20 > independent of Valgrind's terminal I/O, so I think you'd be=20 > commonly launching them in separate windows anyway. It hadn't actually occurred to me to do this the other way round = (Valgrind launches GDB) but that could work ok. >=20 > > c) poor support for getting data from Valgrind's tools (e.g.=20 > > memcheck). The GDB protocol was never really designed for this. >=20 > Yep, that would be nice to have. Do you have any more=20 > concrete thoughts? It seems like a difficult problem,=20 > because there's nothing generic about a Tool; they can get=20 > very special purpose. How does one represent that on the=20 > wire, and how can a generic debugger deal with it once its there? Tools would publish their own API helper libraries. These would = interpret the data stored in the tool specific area of the shared memory region. A client could ask the API what information the tool provided. A client = would either request this information as a binary structure, which it would = then need to interpret, or could ask for it in string form in which case it = would be displayed unprocessed to the user. >=20 > > The only problem with the original shared memory implementation was=20 > > the exposure of internal data structures. To solve this problem I=20 > > propose adding a debugging API shared library to Valgrind. This=20 > > library would be released as part of the Valgrind package and=20 > > installed at the same time. The library could therefore freely use=20 > > access internal data structures without any problems.=20 > Valgrind's core=20 > > would expose useful debugging information, such as registers, and=20 > > debugging control variables such as single stepping through shared=20 > > memory as before (either SysV or mmap). >=20 > (I don't think shared memory would be a good idea. It would=20 > preclude remote machine access, and adds a complex protocol=20 > overhead for synchronizing between the debugger and the=20 > Valgrind threads.) It's not difficult to synchronise between the debugger and Valgrind = threads. That is to say, I encountered no problems implementing this. As for remote machine access, see below. >=20 > > The debugging API would know > > the structure of this shared memory and access it on behalf of user=20 > > processes (such as a debugger). We could also add an API to=20 > Valgrind=20 > > for skins to publish similar skin-specific information. =20 > The debugging=20 > > API would be lightweight and need not necessarily require=20 > many changes=20 > > to Valgrind. >=20 > And the other end of the equation? Are you proposing that we=20 > modify gdb to use this API, and maintain those modifications=20 > as gdb changes? Do you have any other debuggers in mind=20 > which would use it? >=20 > While its certainly possible to do better, it seems that the=20 > gdb protocol has a number of very strong features: > * it exists > * it's stable > * every gdb in the field can already use it The advantage of the debugging API is you can implement the GDB protocol atop of it (e.g. for remote debugging or to support debuggers without a Valgrind target), but you are not limited to it. It also means the GDB server can be a separate component, whereas without the API it would be = more closely coupled to the Valgrind core. >=20 > I definitely like the idea of having some way to use the=20 > Tool's metadata in a debugging context, but I think the first=20 > step is to get some useful debugging functionality. Once we=20 > have that, we can explore ways of improving it/replacing it=20 > with improvements. Is the protocol really completely inextensible? I already have a set of patches that implement useful debugging functionality. The current question is what is the 'right' way to do it. = > One other thing we could look at is reviving Nick's=20 > interactive mode stuff. I'm guessing it has aged rather a lot. Chris |
|
From: Jeremy F. <je...@go...> - 2005-01-08 19:55:56
|
It turns out the threading changes made this pretty simple to get working: $ valgrind --tool=none --single-step=yes valgrind --tool=none echo 'I simulate, therefore I am.' ==11451== Nulgrind, a binary JIT-compiler for x86-linux. ==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==11451== For more details, rerun with: -v ==11451== >==11451== Nulgrind, a binary JIT-compiler for x86-linux. >==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. >==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. >==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. >==11451== For more details, rerun with: -v >==11451== I simulate, therefore I am. >==11451== ==11451== |
|
From: Jeremy F. <je...@go...> - 2005-01-08 19:53:31
|
On Sat, 2005-01-08 at 16:56 +0000, Chris January wrote:
> This seemed like
> the 'right' solution at the time because GDB didn't need to have special
> knowledge about Valgrind (or so I thought) and I began implementing it but
> didn't have enough time to finish.
How far did you get?
> However now I am revisiting the problem
> and have concluded that this idea is not the best solution because:
> a) it is limited to debuggers implenting the GDB remote debugging protocol.
I'm not terribly worried about that, especially since the set of
debuggers implementing the gdb protocol is vastly larger than the set
using a special Valgrind library.
> b) it still needs a specialised Valgrind target for GDB to launch Valgrind
> and connect to the server port in one operation. (I suppose it would be
> feasible to have the user manually launch Valgrind and then have Valgrind
> wait for GDB to connect but this is less than ideal.)
Valgrind could do that itself, if that were a major concern. One of the
nice things about having gdb separate is that its independent of
Valgrind's terminal I/O, so I think you'd be commonly launching them in
separate windows anyway.
> c) poor support for getting data from Valgrind's tools (e.g. memcheck). The
> GDB protocol was never really designed for this.
Yep, that would be nice to have. Do you have any more concrete
thoughts? It seems like a difficult problem, because there's nothing
generic about a Tool; they can get very special purpose. How does one
represent that on the wire, and how can a generic debugger deal with it
once its there?
> The only problem with the original shared memory implementation was the
> exposure of internal data structures. To solve this problem I propose adding
> a debugging API shared library to Valgrind. This library would be released
> as part of the Valgrind package and installed at the same time. The library
> could therefore freely use access internal data structures without any
> problems. Valgrind's core would expose useful debugging information, such as
> registers, and debugging control variables such as single stepping through
> shared memory as before (either SysV or mmap).
(I don't think shared memory would be a good idea. It would preclude
remote machine access, and adds a complex protocol overhead for
synchronizing between the debugger and the Valgrind threads.)
> The debugging API would know
> the structure of this shared memory and access it on behalf of user
> processes (such as a debugger). We could also add an API to Valgrind for
> skins to publish similar skin-specific information. The debugging API would
> be lightweight and need not necessarily require many changes to Valgrind.
And the other end of the equation? Are you proposing that we modify gdb
to use this API, and maintain those modifications as gdb changes? Do
you have any other debuggers in mind which would use it?
While its certainly possible to do better, it seems that the gdb
protocol has a number of very strong features:
* it exists
* it's stable
* every gdb in the field can already use it
I definitely like the idea of having some way to use the Tool's metadata
in a debugging context, but I think the first step is to get some useful
debugging functionality. Once we have that, we can explore ways of
improving it/replacing it with improvements. Is the protocol really
completely inextensible?
One other thing we could look at is reviving Nick's interactive mode
stuff. I'm guessing it has aged rather a lot.
J
|
|
From: Chris J. <ch...@at...> - 2005-01-08 16:56:17
|
In which I propose adding a shared library that implements an API for accessing internal Valgrind data structures and tool-specific = information. Some time ago I submitted a patch to implement breakpoints and single stepping in Valgrind. Hopefully that patch can be revisited and = committed at some stage because I have a proposal that builds on that patch to make. As some of you may know I wrote some patches for Valgrind and GDB that allowed GDB to debug processes running under Valgrind. I moved the VG_(threads) structure to a shared memory region so that GDB could read = the register set of the threads from the structure. I also added a control variable to enable single stepping. Now although this method worked fine = it was fragile because GDB needed to have intimate knowledge of the VG_(threads) structure. I later proposed an alternative solution in = which Valgrind provided a GDB server that GDB could connect to. This seemed = like the 'right' solution at the time because GDB didn't need to have special knowledge about Valgrind (or so I thought) and I began implementing it = but didn't have enough time to finish. However now I am revisiting the = problem and have concluded that this idea is not the best solution because: a) it is limited to debuggers implenting the GDB remote debugging = protocol. b) it still needs a specialised Valgrind target for GDB to launch = Valgrind and connect to the server port in one operation. (I suppose it would be feasible to have the user manually launch Valgrind and then have = Valgrind wait for GDB to connect but this is less than ideal.) c) poor support for getting data from Valgrind's tools (e.g. memcheck). = The GDB protocol was never really designed for this. The only problem with the original shared memory implementation was the exposure of internal data structures. To solve this problem I propose = adding a debugging API shared library to Valgrind. This library would be = released as part of the Valgrind package and installed at the same time. The = library could therefore freely use access internal data structures without any problems. Valgrind's core would expose useful debugging information, = such as registers, and debugging control variables such as single stepping = through shared memory as before (either SysV or mmap). The debugging API would = know the structure of this shared memory and access it on behalf of user processes (such as a debugger). We could also add an API to Valgrind for skins to publish similar skin-specific information. The debugging API = would be lightweight and need not necessarily require many changes to = Valgrind. Comments and criticism welcome. Chris -- http://www.atomice.com |
|
From: <js...@ac...> - 2005-01-08 03:56:34
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-08 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 188 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-08 03:24:11
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-08 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 6106 Illegal instruction VALGRINDLIB=/tmp/valgrind.22439/valgrind/.in_place /tmp/valgrind.22439/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:20:07
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-08 03:15:04 GMT 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 -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:13:53
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-08 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:08:34
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-08 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:04:03
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-08 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-07 07:59:41
|
On Thu, 2005-01-06 at 21:06 -0800, Jeremy Fitzhardinge wrote: > The basic idea came from Eric Estievenart in a discussion earlier this > year. Erm, last year. I should have proofread the draft? J |
|
From: Jeremy F. <je...@go...> - 2005-01-07 05:06:31
|
Over the hols I decided it would be fun to rewrite Valgrind's syscall/threading stuff again. The basic idea came from Eric Estievenart in a discussion earlier this year. Rather than having the "main thread" with a bunch of proxy LWP threads to deal with signals and so on, every app-level thread gets its own kernel-level thread, so that the thread/process structure of the program is identical inside and outside Valgrind. The thread execution is still serialized, so that only one client thread can run at once. In addition to this change, I killed Valgrind's pthread library. Instead, Valgrind supports the clone syscall, plus all the other threading-related syscalls (futex, set_thread_area, set_pid_address, gettid, tkill, tgkill, etc). This allows the system threads library to work under Valgrind. I don't support full general clone, but it does work with both NPTL and LinuxThreads, as well as using clone() to do fork and vfork (vfork is mapped to fork, as before). The chief advantage of these changes is simplicity. Valgrind now implements a much thinner layer over the kernel, and doesn't try to second-guess the kernel's behaviour. This means, for example, that there's no more "mode switch" for 2.4 and 2.6-style kernels - they both work equally well, despite having significant differences in thread support and signal handling. vg_libthread has been becoming increasingly troublesome, and is basically completely broken (for example, when using a multithreaded program with a Tool which doesn't replace malloc, there was no locking to protect the libc malloc from concurrent access). Any system thread library should work now, including home-rolled ones (with a bit of tweaking). All this has resulted in Valgrind shrinking by about 6600 lines of code, including all of vg_proxylwp.c, vg_libpthread.c and about 2200 lines from vg_scheduler.c - some of the hairest, trickiest and error-prone code in the codebase. There are some disadvantages though. In losing vg_libpthread, Valgrind has a much more limited understanding of what's going on inside a threaded program. It can see threads starting and exiting, but that's about it. It can't tell when a mutex has been locked or unlocked; it can't even really tell which threads are waiting for another to exit. This means that all the core pthreads error reporting has gone, and helgrind is basically useless. We can probably glean a bit more information than we currently are, but not a lot. Probably the best way to fix this is to work with the glibc people to try to build some Valgrind support into glibc, and/or take advantage of the existing hooks which gdb uses. I haven't investigated this at all yet. The patch as it currently stands works well for me. I've mostly tested it on my FC2/2.6.10 system, using both LinuxThreads and NPTL threads libraries. The regression tests mostly pass, and I can run OOo and firefox under nulgrind and memcheck. Other changes: I took advantage of the general upheaval to try to isolate more of the OS/arch/platform dependent code. vg_scheduler is now (almost?) completely free of OS-specific knowledge: it just assumes there are things called threads, they can be running or blocked, interrupted by async events, and eventually they exit, but all the details are left up to other OS-specific code. Also, one widespread change was renaming get_current_tid to get_VCPU_tid. The old name was too ambiguous in the context of the new threading, and the new name better describes what it actually does. So, the patch is at http://www.goop.org/~jeremy/valgrind/new-threading.patch.bz2 If people could try it out and see if it basically works for them, I'll check it in the next few days. In particular, I'd like it if the people considering porting Valgrind to other OS's could have a look and see how these changes affect them. TODO: * Examine all the regression test failures, and work out what's going on. Some are trivial (thread IDs have changed), some are irrelevent (pthreads error checking) and some are strange (particularly the programs which work when run standalone, but fail when run in harness). * Examine all the new errors popping out of libpthread, and work out what's going on. Some need suppressing, but some might be real bugs (in either Valgrind or libpthread). * Test on more machines. I did a brief test on an RH7.3/2.4 machine, and it nearly worked. It seems that its libpthread does something interesting with segment registers which isn't supported by Valgrind. I think it wants LDT entries shared between threads. It should be possible to get 2.4 (or even 2.2 if we wanted to) systems supported without too much programming effort. * Try to recover the lost pthreads functionality. All that pthreads API usage checking was useful, and it uncovered a lot of bugs. We should do as much as we can to try to work out what the client is doing using available evidence, and also look into getting help from the threads library. The tricky part will be making sure this doesn't end up being another track-the-version-of-the-day maintenance headache. * I implemented the thread-serializing run_sema with both a futex and a pipe-based token-passing scheme. The futex code is more efficient, but the pipe scheme works everywhere, so that's what is enabled by default. Switching is a compile-time option, but it could be done at runtime. WOULD LIKE TO DO (comments?): * I noticed that ThreadState * and ThreadId are synonyms, and there's a lot of redundant code for converting between the two. I would like to drop ThreadId, and just use ThreadState * everywhere. Outside the core, it would just be an opaque pointer. * As a corollary, I would also like to get rid of the VG_(threads) array and dynamically allocate ThreadState structures, and get rid of the hard upper limit of VG_N_THREADS. The only significant bad effect this might have is on Tools which maintain their own arrays for storing per-thread information (like helgrind). We can just change them to add a per-thread-info-for-Tools field to ThreadState. J |
|
From: <js...@ac...> - 2005-01-07 03:59:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-07 03:50:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 188 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-07 03:24:21
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-07 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 31496 Illegal instruction VALGRINDLIB=/tmp/valgrind.15455/valgrind/.in_place /tmp/valgrind.15455/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:20:21
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-07 03:15:02 GMT 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 -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:13:53
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-07 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |