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
(32) |
2
(22) |
3
(47) |
4
(29) |
5
(18) |
6
(16) |
|
7
(21) |
8
(29) |
9
(23) |
10
(68) |
11
(20) |
12
(17) |
13
(17) |
|
14
(27) |
15
(26) |
16
(21) |
17
(13) |
18
(19) |
19
(29) |
20
(13) |
|
21
(9) |
22
(8) |
23
(29) |
24
(56) |
25
(21) |
26
(46) |
27
(33) |
|
28
(25) |
29
(41) |
30
(35) |
31
(28) |
|
|
|
|
From: <sv...@va...> - 2005-08-27 19:35:45
|
Author: njn Date: 2005-08-27 20:35:42 +0100 (Sat, 27 Aug 2005) New Revision: 4544 Log: Removed incorrectly dup'd text. Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-27 19:30:36 UTC (rev 4= 543) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-27 19:35:42 UTC (rev 4= 544) @@ -72,8 +72,6 @@ =20 109345 ppc32 ptrace patch available should be applied =20 -Should fix for 3.1. Any fix would be similar to that for 110274. - FIXED-TRUNK: TODO FIXED-30BRANCH: won't (3.1 fix only) =20 |
|
From: <sv...@va...> - 2005-08-27 19:30:41
|
Author: njn Date: 2005-08-27 20:30:36 +0100 (Sat, 27 Aug 2005) New Revision: 4543 Log: Add .txt extensions to those files missing them, for consistency. Added: trunk/docs/internals/release-HOWTO.txt trunk/docs/internals/roadmap.txt Removed: trunk/docs/internals/release-HOWTO trunk/docs/internals/roadmap Modified: trunk/docs/internals/Makefile.am Modified: trunk/docs/internals/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/Makefile.am 2005-08-27 18:00:21 UTC (rev 4542) +++ trunk/docs/internals/Makefile.am 2005-08-27 19:30:36 UTC (rev 4543) @@ -3,7 +3,7 @@ m_replacemalloc.txt \ m_syswrap.txt module-structure.txt notes.txt porting-HOWTO.txt \ porting-to-ARM.txt \ - release-HOWTO roadmap \ + release-HOWTO.txt roadmap.txt \ segments-seginfos.txt threads-syscalls-signals.txt \ tm-mutexstates.dot tm-threadstates.dot tracking-fn-entry-exit.txt \ xml-output.txt Deleted: trunk/docs/internals/release-HOWTO =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/release-HOWTO 2005-08-27 18:00:21 UTC (rev 4542) +++ trunk/docs/internals/release-HOWTO 2005-08-27 19:30:36 UTC (rev 4543) @@ -1,111 +0,0 @@ -------------------------------------------------------------------------= ----- -TODO list when doing a Valgrind release (with release number "X.Y.Z") -------------------------------------------------------------------------= ----- - -First of all: - -- Tell valgrind-developers you want to do a release. Give a timeframe f= or - everyone to check in any final features/bug-fixes they want in the - release. - -- Go over the docs, make sure they're up to date. - -- Update version number and date in docs/xml/vg-entities.xml. (Exact - release date probably won't be known yet, updating it is in the list b= elow - of tasks for the official release.) - -- Write release notes, add to NEWS. Include a list of fixed bugs from - Bugzilla. It's unclear how to do this consistently. The approach - taken for 3.0.0 was to go to this page in KDE's bugzilla: - http://bugs.kde.org/query.cgi - and to create a search where - "Status and severity" / Status field is set to RESOLVED - and - "Involved People" / Email, bug-owner contains "jseward" - since I believe js...@ac... is the owner of all bugs. - This creates a long list of bugs which does not conveniently stop=20 - at the previous release. Work backwards through this list until - either (1) you run out of patience, or (2) most of the bugs seem - to pertain to previous releases and are now irrelevant. In short - this is not a very scientific or robust way to collect up all - bugs fixed since last time. - -- Other files that might need updating: README, README_DEVELOPERS, - README_PACKAGERS. - -- Add X.Y.Z and X.Y.Z.SVN versions to Bugzilla (ask Dirk to do it) - -- If there are any binary incompatible tool API changes against the last - stable release, ensure that VG_CORE_INTERFACE_VERSION in - include/pub_tool_tooliface.h has been increased since the last release= . - - -For each release candidate (should do release candidates for big release= s, -bug-fix-only releases might not need one): - -- Do pre-release testing: - - Make sure regtests run ok on all platforms of interest. - - Make sure Mozilla and OpenOffice run ok on all platforms of interest= . - -- Change release number in AC_INIT() in configure.in to "X.Y.Z-rcN", whe= re - 'N' is the release candidate number. - -- Make the tarball ("make dist") and put it on the web somewhere (it doe= sn't - have to be on valgrind.org if another site is easier). - -- Ensure the tarball builds, runs, regtests on the platforms of interest= . - However redundant this seems, sometimes it can be that a from-the-repo - build works whereas a from-the-tarball one doesn't, usually due to som= e - trivial installation problem. - -- Announce the release: - - Email valgrind-users and valgrind-developers (but not valgrind-annou= nce). =20 - - Make clear it's a release candidate. =20 - - Make sure you tell everyone where to download from. - - Include the release notes in the email (maybe not necessary for rele= ase - candidates 2+). - -- Wait 2--3 days for feedback. If bugs appear: - - Fix them. - - Update the bug-fix list in NEWS if necessary. - - Do another release candidate. - - -For the official release: - -- Again, update date in docs/xml/vg-entities.xml for the official releas= e - date. - -- Do pre-release testing: - - Make sure regtests run ok on all platforms of interest. - - Make sure Mozilla and OpenOffice run ok on all platforms of interest= . - -- Change release number in AC_INIT() in configure.in to "X.Y.Z". - -- Make the tarball ("make dist"). - -- Check tarball builds, installs, regtests on platforms of interest. - If not, fix and repeat until success. - -- Tag the repository ("VALGRIND_X_Y_Z"). - =20 -- Update website:=20 - - Put the tarball up. - - Update the docs -- both the tarball'd docs, and the online-readable = docs. - - Update www.valgrind.org/downloads/source_code.html. =20 - - Update www.valgrind.org/downloads/archive.html. =20 - - Put the release notes at www.valgrind.org/info/release-notes-X.Y.Z.t= xt. - - Add a news item to the front page and also to valgrind.org/info/news= .html. - Include a link to the release notes. - - Update the "release-date" and "release-version" in php/.htconfx. - - Other pages that might need updating: devel/cvs_svn.html. - -- Change release number in AC_INIT() in configure.in to "X.Y.Z.SVN", whe= re - X.Y.Z is one more than the release just done. - -- Announce the release: - - Email valgrind-users, valgrind-developers, and valgrind-announce. - - Email Linux Weekly News. - - Include the release notes in the email. - -- Go on holiday. Copied: trunk/docs/internals/release-HOWTO.txt (from rev 4539, trunk/docs= /internals/release-HOWTO) Deleted: trunk/docs/internals/roadmap =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/roadmap 2005-08-27 18:00:21 UTC (rev 4542) +++ trunk/docs/internals/roadmap 2005-08-27 19:30:36 UTC (rev 4543) @@ -1,42 +0,0 @@ -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D -Valgrind Roadmap -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - -This file serves as a rough roadmap for Valgrind development. It shows = a -minimal set of features we hope to implement for each version. It's in -reverse chronological order. - -------------------------------------------------------------------------= ----- -3.1.0 -------------------------------------------------------------------------= ----- -Scheduled for around November 2005. - -Definite --------- -* Get 32-bit and 64-bit programs working smoothly on AMD64 (Tom?). Seve= ral - levels of smoothness here, we should aim for at least level 3. - - 1. Be able to build a 32-bit valgrind on a 64-bit machine, so you can - build and install both, and manually choose between bin/valgrind an= d - bin64/valgrind. - 2. Build both automatically when installing. - 3. Choose the appropriate executable automatically at startup just fro= m - "valgrind". - 4. With --trace-children=3Dyes, allow 32-bit programs to exec 64-bit - programs and vice versa, and invoke the appropriate Valgrind - automatically. - -* Get PPC32 working usably with Memcheck (Julian). Has already improved= a - lot since. Get Cachegrind working with it (Nick). - -* Rewrite address space manager; statically link the core with - each tool; remove all glibc dependencies (Julian). - -Maybe ------ -* Get pthread modelling and Helgrind working again. Requires function - wrapping (Nick). - -* Reinstate Addrcheck and/or implement V-bit compression in Memcheck (?)= . - - Copied: trunk/docs/internals/roadmap.txt (from rev 4541, trunk/docs/inter= nals/roadmap) |
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 19:25:59
|
On Sat, 27 Aug 2005, Tom Hughes wrote: >> Perhaps we can switch to showing the number of seconds elapsed since >> startup. Because people might use --trace-children=yes, we'd want a >> command-line arg with which you can pass a starting value for this. >> Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass >> --initial-time-stamp=5 to bar so that the elapsed times were in sync. > > The only problem with that is that the reason given in the original > request (bug #70587) for wanting this was to be able to match up things > in the valgrind logs with other log files which will probably have > absolute times. Oh. I'm out of ideas, then. N |
|
From: Tom H. <to...@co...> - 2005-08-27 18:05:09
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sat, 27 Aug 2005, Tom Hughes wrote:
>
> > I can't really see how we can sensibly do localtime_r - reading and
> > handling the timezone database is just going to get silly.
>
> Perhaps we can switch to showing the number of seconds elapsed since
> startup. Because people might use --trace-children=yes, we'd want a
> command-line arg with which you can pass a starting value for this.
> Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass
> --initial-time-stamp=5 to bar so that the elapsed times were in sync.
The only problem with that is that the reason given in the original
request (bug #70587) for wanting this was to be able to match up things
in the valgrind logs with other log files which will probably have
absolute times.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-08-27 18:00:26
|
Author: njn Date: 2005-08-27 19:00:21 +0100 (Sat, 27 Aug 2005) New Revision: 4542 Log: update for new files Modified: trunk/docs/internals/Makefile.am Modified: trunk/docs/internals/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/Makefile.am 2005-08-27 17:58:09 UTC (rev 4541) +++ trunk/docs/internals/Makefile.am 2005-08-27 18:00:21 UTC (rev 4542) @@ -1,8 +1,9 @@ EXTRA_DIST =3D \ - 64-bit-cleanness.txt directory-structure.txt m_replacemalloc.txt \ + 3_0_BUGSTATUS 64-bit-cleanness.txt directory-structure.txt \ + m_replacemalloc.txt \ m_syswrap.txt module-structure.txt notes.txt porting-HOWTO.txt \ porting-to-ARM.txt \ - release-HOWTO \ + release-HOWTO roadmap \ segments-seginfos.txt threads-syscalls-signals.txt \ tm-mutexstates.dot tm-threadstates.dot tracking-fn-entry-exit.txt \ xml-output.txt |
|
From: <sv...@va...> - 2005-08-27 17:58:11
|
Author: njn Date: 2005-08-27 18:58:09 +0100 (Sat, 27 Aug 2005) New Revision: 4541 Log: tweak Modified: trunk/docs/internals/roadmap Modified: trunk/docs/internals/roadmap =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/roadmap 2005-08-27 17:55:22 UTC (rev 4540) +++ trunk/docs/internals/roadmap 2005-08-27 17:58:09 UTC (rev 4541) @@ -1,15 +1,18 @@ -------------------------------------------------------------------------= ----- -Valgrind roadmap -------------------------------------------------------------------------= ----- +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D +Valgrind Roadmap +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 This file serves as a rough roadmap for Valgrind development. It shows = a minimal set of features we hope to implement for each version. It's in reverse chronological order. =20 +------------------------------------------------------------------------= ----- 3.1.0 ------ +------------------------------------------------------------------------= ----- Scheduled for around November 2005. =20 +Definite +-------- * Get 32-bit and 64-bit programs working smoothly on AMD64 (Tom?). Seve= ral levels of smoothness here, we should aim for at least level 3. =20 @@ -29,3 +32,11 @@ * Rewrite address space manager; statically link the core with each tool; remove all glibc dependencies (Julian). =20 +Maybe +----- +* Get pthread modelling and Helgrind working again. Requires function + wrapping (Nick). + +* Reinstate Addrcheck and/or implement V-bit compression in Memcheck (?)= . + + |
|
From: <sv...@va...> - 2005-08-27 17:55:27
|
Author: njn Date: 2005-08-27 18:55:22 +0100 (Sat, 27 Aug 2005) New Revision: 4540 Log: Added a roadmap document, intended to indicate what features we're aiming to put in future releases. Added: trunk/docs/internals/roadmap Added: trunk/docs/internals/roadmap =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/roadmap 2005-08-27 17:31:43 UTC (rev 4539) +++ trunk/docs/internals/roadmap 2005-08-27 17:55:22 UTC (rev 4540) @@ -0,0 +1,31 @@ +------------------------------------------------------------------------= ----- +Valgrind roadmap +------------------------------------------------------------------------= ----- + +This file serves as a rough roadmap for Valgrind development. It shows = a +minimal set of features we hope to implement for each version. It's in +reverse chronological order. + +3.1.0 +----- +Scheduled for around November 2005. + +* Get 32-bit and 64-bit programs working smoothly on AMD64 (Tom?). Seve= ral + levels of smoothness here, we should aim for at least level 3. + + 1. Be able to build a 32-bit valgrind on a 64-bit machine, so you can + build and install both, and manually choose between bin/valgrind an= d + bin64/valgrind. + 2. Build both automatically when installing. + 3. Choose the appropriate executable automatically at startup just fro= m + "valgrind". + 4. With --trace-children=3Dyes, allow 32-bit programs to exec 64-bit + programs and vice versa, and invoke the appropriate Valgrind + automatically. + +* Get PPC32 working usably with Memcheck (Julian). Has already improved= a + lot since. Get Cachegrind working with it (Nick). + +* Rewrite address space manager; statically link the core with + each tool; remove all glibc dependencies (Julian). + |
|
From: <sv...@va...> - 2005-08-27 17:31:48
|
Author: njn Date: 2005-08-27 18:31:43 +0100 (Sat, 27 Aug 2005) New Revision: 4539 Log: update Modified: trunk/docs/internals/release-HOWTO Modified: trunk/docs/internals/release-HOWTO =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/release-HOWTO 2005-08-27 17:20:53 UTC (rev 4538) +++ trunk/docs/internals/release-HOWTO 2005-08-27 17:31:43 UTC (rev 4539) @@ -94,7 +94,9 @@ - Update the docs -- both the tarball'd docs, and the online-readable = docs. - Update www.valgrind.org/downloads/source_code.html. =20 - Update www.valgrind.org/downloads/archive.html. =20 + - Put the release notes at www.valgrind.org/info/release-notes-X.Y.Z.t= xt. - Add a news item to the front page and also to valgrind.org/info/news= .html. + Include a link to the release notes. - Update the "release-date" and "release-version" in php/.htconfx. - Other pages that might need updating: devel/cvs_svn.html. =20 |
|
From: <sv...@va...> - 2005-08-27 17:29:55
|
Author: njn Date: 2005-08-27 18:29:51 +0100 (Sat, 27 Aug 2005) New Revision: 181 Log: whoops Added: trunk/info/release-notes-3.0.0.txt Removed: trunk/release-notes-3.0.0.txt Copied: trunk/info/release-notes-3.0.0.txt (from rev 180, trunk/release-n= otes-3.0.0.txt) Deleted: trunk/release-notes-3.0.0.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/release-notes-3.0.0.txt 2005-08-27 17:29:02 UTC (rev 180) +++ trunk/release-notes-3.0.0.txt 2005-08-27 17:29:51 UTC (rev 181) @@ -1,154 +0,0 @@ - -Release 3.0.0 (3 August 2005) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -3.0.0 is a major overhaul of Valgrind. The most significant user -visible change is that Valgrind now supports architectures other than -x86. The new architectures it supports are AMD64 and PPC32, and the -infrastructure is present for other architectures to be added later. - -AMD64 support works well, but has some shortcomings: - -- It generally won't be as solid as the x86 version. For example, - support for more obscure instructions and system calls may be missing. - We will fix these as they arise. - -- Address space may be limited; see the point about - position-independent executables below. - -- If Valgrind is built on an AMD64 machine, it will only run 64-bit - executables. If you want to run 32-bit x86 executables under Valgrind - on an AMD64, you will need to build Valgrind on an x86 machine and - copy it to the AMD64 machine. And it probably won't work if you do - something tricky like exec'ing a 32-bit program from a 64-bit program - while using --trace-children=3Dyes. We hope to improve this situation - in the future. - -The PPC32 support is very basic. It may not work reliably even for -small programs, but it's a start. Many thanks to Paul Mackerras for -his great work that enabled this support. We are working to make -PPC32 usable as soon as possible. - -Other user-visible changes: - -- Valgrind is no longer built by default as a position-independent - executable (PIE), as this caused too many problems. - - Without PIE enabled, AMD64 programs will only be able to access 2GB of - address space. We will fix this eventually, but not for the moment. - =20 - Use --enable-pie at configure-time to turn this on. - -- Support for programs that use stack-switching has been improved. Use - the --max-stackframe flag for simple cases, and the - VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and - VALGRIND_STACK_CHANGE client requests for trickier cases. - -- Support for programs that use self-modifying code has been improved, - in particular programs that put temporary code fragments on the stack. - This helps for C programs compiled with GCC that use nested functions, - and also Ada programs. This is controlled with the --smc-check - flag, although the default setting should work in most cases. - -- Output can now be printed in XML format. This should make it easier - for tools such as GUI front-ends and automated error-processing - schemes to use Valgrind output as input. The --xml flag controls this= . - As part of this change, ELF directory information is read from executa= bles, - so absolute source file paths are available if needed. - -- Programs that allocate many heap blocks may run faster, due to - improvements in certain data structures. - -- Addrcheck is currently not working. We hope to get it working again - soon. Helgrind is still not working, as was the case for the 2.4.0 - release. - -- The JITter has been completely rewritten, and is now in a separate - library, called Vex. This enabled a lot of the user-visible changes, - such as new architecture support. The new JIT unfortunately translate= s - more slowly than the old one, so programs may take longer to start. - We believe the code quality is produces is about the same, so once - started, programs should run at about the same speed. Feedback about - this would be useful. - - On the plus side, Vex and hence Memcheck tracks value flow properly - through floating point and vector registers, something the 2.X line - could not do. That means that Memcheck is much more likely to be - usably accurate on vectorised code. - -- There is a subtle change to the way exiting of threaded programs - is handled. In 3.0, Valgrind's final diagnostic output (leak check, - etc) is not printed until the last thread exits. If the last thread - to exit was not the original thread which started the program, any - other process wait()-ing on this one to exit may conclude it has - finished before the diagnostic output is printed. This may not be - what you expect. 2.X had a different scheme which avoided this - problem, but caused deadlocks under obscure circumstances, so we - are trying something different for 3.0. - -- Small changes in control log file naming which make it easier to - use valgrind for debugging MPI-based programs. The relevant - new flags are --log-file-exactly=3D and --log-file-qualifier=3D. - -- As part of adding AMD64 support, DWARF2 CFI-based stack unwinding - support was added. In principle this means Valgrind can produce - meaningful backtraces on x86 code compiled with -fomit-frame-pointer - providing you also compile your code with -fasynchronous-unwind-tables= . - -- The documentation build system has been completely redone. - The documentation masters are now in XML format, and from that - HTML, PostScript and PDF documentation is generated. As a result - the manual is now available in book form. Note that the - documentation in the source tarballs is pre-built, so you don't need - any XML processing tools to build Valgrind from a tarball. - -Changes that are not user-visible: - -- The code has been massively overhauled in order to modularise it. - As a result we hope it is easier to navigate and understand. - -- Lots of code has been rewritten. - -BUGS FIXED: - -110046 sz =3D=3D 4 assertion failed=20 -109810 vex amd64->IR: unhandled instruction bytes: 0xA3 0x4C 0x70 0xD7 -109802 Add a plausible_stack_size command-line parameter ? -109783 unhandled ioctl TIOCMGET (running hw detection tool discover)=20 -109780 unhandled ioctl BLKSSZGET (running fdisk -l /dev/hda) -109718 vex x86->IR: unhandled instruction: ffreep=20 -109429 AMD64 unhandled syscall: 127 (sigpending) -109401 false positive uninit in strchr from ld-linux.so.2 -109385 "stabs" parse failure=20 -109378 amd64: unhandled instruction REP NOP -109376 amd64: unhandled instruction LOOP Jb=20 -109363 AMD64 unhandled instruction bytes=20 -109362 AMD64 unhandled syscall: 24 (sched_yield) -109358 fork() won't work with valgrind-3.0 SVN -109332 amd64 unhandled instruction: ADC Ev, Gv -109314 Bogus memcheck report on amd64 -108883 Crash; vg_memory.c:905 (vgPlain_init_shadow_range): - Assertion `vgPlain_defined_init_shadow_page()' failed. -108349 mincore syscall parameter checked incorrectly=20 -108059 build infrastructure: small update -107524 epoll_ctl event parameter checked on EPOLL_CTL_DEL -107123 Vex dies with unhandled instructions: 0xD9 0x31 0xF 0xAE -106841 auxmap & openGL problems -106713 SDL_Init causes valgrind to exit -106352 setcontext and makecontext not handled correctly=20 -106293 addresses beyond initial client stack allocation=20 - not checked in VALGRIND_DO_LEAK_CHECK -106283 PIE client programs are loaded at address 0 -105831 Assertion `vgPlain_defined_init_shadow_page()' failed. -105039 long run-times probably due to memory manager=20 -104797 valgrind needs to be aware of BLKGETSIZE64 -103594 unhandled instruction: FICOM -103320 Valgrind 2.4.0 fails to compile with gcc 3.4.3 and -O0 -103168 potentially memory leak in coregrind/ume.c=20 -102039 bad permissions for mapped region at address 0xB7C73680 -101881 weird assertion problem -101543 Support fadvise64 syscalls -75247 x86_64/amd64 support (the biggest "bug" we have ever fixed) - -(3.0RC1: 27 July 05, vex r1303, valgrind r4283). -(3.0.0: 3 August 05, vex r1313, valgrind r4316). - |
|
From: <sv...@va...> - 2005-08-27 17:29:04
|
Author: njn Date: 2005-08-27 18:29:02 +0100 (Sat, 27 Aug 2005) New Revision: 180 Log: Put the 3.0.0 release notes on the site, link from the 3.0.0 release news item. Added: trunk/release-notes-3.0.0.txt Modified: trunk/index.html trunk/info/news.html Modified: trunk/index.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/index.html 2005-08-15 04:44:10 UTC (rev 179) +++ trunk/index.html 2005-08-27 17:29:02 UTC (rev 180) @@ -38,7 +38,8 @@ <ul> =20 <li><p>August 3 2005: Valgrind 3.0.0, for x86-linux and amd64-linux,=20 - is available.</p></li> + is available + (<a href=3D"/info/release-notes-3.0.0.txt">release notes</a>).</p></li= > =20 <li><p>August 1 2005: A new stable version, 2.4.1, is available.</p></li> Modified: trunk/info/news.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/info/news.html 2005-08-15 04:44:10 UTC (rev 179) +++ trunk/info/news.html 2005-08-27 17:29:02 UTC (rev 180) @@ -7,7 +7,8 @@ =20 <ul> =20 - <li><p>August 3 2005: A new stable version, 3.0.0 is available. + <li><p>August 3 2005: A new stable version, 3.0.0 is available + (<a href=3D"/info/release-notes-3.0.0.txt">release notes</a>). 3.0.0 is a major new release, with support for both x86-linux and=20 amd64-linux, and many other improvements.</p></li> =20 Added: trunk/release-notes-3.0.0.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/release-notes-3.0.0.txt 2005-08-15 04:44:10 UTC (rev 179) +++ trunk/release-notes-3.0.0.txt 2005-08-27 17:29:02 UTC (rev 180) @@ -0,0 +1,154 @@ + +Release 3.0.0 (3 August 2005) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +3.0.0 is a major overhaul of Valgrind. The most significant user +visible change is that Valgrind now supports architectures other than +x86. The new architectures it supports are AMD64 and PPC32, and the +infrastructure is present for other architectures to be added later. + +AMD64 support works well, but has some shortcomings: + +- It generally won't be as solid as the x86 version. For example, + support for more obscure instructions and system calls may be missing. + We will fix these as they arise. + +- Address space may be limited; see the point about + position-independent executables below. + +- If Valgrind is built on an AMD64 machine, it will only run 64-bit + executables. If you want to run 32-bit x86 executables under Valgrind + on an AMD64, you will need to build Valgrind on an x86 machine and + copy it to the AMD64 machine. And it probably won't work if you do + something tricky like exec'ing a 32-bit program from a 64-bit program + while using --trace-children=3Dyes. We hope to improve this situation + in the future. + +The PPC32 support is very basic. It may not work reliably even for +small programs, but it's a start. Many thanks to Paul Mackerras for +his great work that enabled this support. We are working to make +PPC32 usable as soon as possible. + +Other user-visible changes: + +- Valgrind is no longer built by default as a position-independent + executable (PIE), as this caused too many problems. + + Without PIE enabled, AMD64 programs will only be able to access 2GB of + address space. We will fix this eventually, but not for the moment. + =20 + Use --enable-pie at configure-time to turn this on. + +- Support for programs that use stack-switching has been improved. Use + the --max-stackframe flag for simple cases, and the + VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and + VALGRIND_STACK_CHANGE client requests for trickier cases. + +- Support for programs that use self-modifying code has been improved, + in particular programs that put temporary code fragments on the stack. + This helps for C programs compiled with GCC that use nested functions, + and also Ada programs. This is controlled with the --smc-check + flag, although the default setting should work in most cases. + +- Output can now be printed in XML format. This should make it easier + for tools such as GUI front-ends and automated error-processing + schemes to use Valgrind output as input. The --xml flag controls this= . + As part of this change, ELF directory information is read from executa= bles, + so absolute source file paths are available if needed. + +- Programs that allocate many heap blocks may run faster, due to + improvements in certain data structures. + +- Addrcheck is currently not working. We hope to get it working again + soon. Helgrind is still not working, as was the case for the 2.4.0 + release. + +- The JITter has been completely rewritten, and is now in a separate + library, called Vex. This enabled a lot of the user-visible changes, + such as new architecture support. The new JIT unfortunately translate= s + more slowly than the old one, so programs may take longer to start. + We believe the code quality is produces is about the same, so once + started, programs should run at about the same speed. Feedback about + this would be useful. + + On the plus side, Vex and hence Memcheck tracks value flow properly + through floating point and vector registers, something the 2.X line + could not do. That means that Memcheck is much more likely to be + usably accurate on vectorised code. + +- There is a subtle change to the way exiting of threaded programs + is handled. In 3.0, Valgrind's final diagnostic output (leak check, + etc) is not printed until the last thread exits. If the last thread + to exit was not the original thread which started the program, any + other process wait()-ing on this one to exit may conclude it has + finished before the diagnostic output is printed. This may not be + what you expect. 2.X had a different scheme which avoided this + problem, but caused deadlocks under obscure circumstances, so we + are trying something different for 3.0. + +- Small changes in control log file naming which make it easier to + use valgrind for debugging MPI-based programs. The relevant + new flags are --log-file-exactly=3D and --log-file-qualifier=3D. + +- As part of adding AMD64 support, DWARF2 CFI-based stack unwinding + support was added. In principle this means Valgrind can produce + meaningful backtraces on x86 code compiled with -fomit-frame-pointer + providing you also compile your code with -fasynchronous-unwind-tables= . + +- The documentation build system has been completely redone. + The documentation masters are now in XML format, and from that + HTML, PostScript and PDF documentation is generated. As a result + the manual is now available in book form. Note that the + documentation in the source tarballs is pre-built, so you don't need + any XML processing tools to build Valgrind from a tarball. + +Changes that are not user-visible: + +- The code has been massively overhauled in order to modularise it. + As a result we hope it is easier to navigate and understand. + +- Lots of code has been rewritten. + +BUGS FIXED: + +110046 sz =3D=3D 4 assertion failed=20 +109810 vex amd64->IR: unhandled instruction bytes: 0xA3 0x4C 0x70 0xD7 +109802 Add a plausible_stack_size command-line parameter ? +109783 unhandled ioctl TIOCMGET (running hw detection tool discover)=20 +109780 unhandled ioctl BLKSSZGET (running fdisk -l /dev/hda) +109718 vex x86->IR: unhandled instruction: ffreep=20 +109429 AMD64 unhandled syscall: 127 (sigpending) +109401 false positive uninit in strchr from ld-linux.so.2 +109385 "stabs" parse failure=20 +109378 amd64: unhandled instruction REP NOP +109376 amd64: unhandled instruction LOOP Jb=20 +109363 AMD64 unhandled instruction bytes=20 +109362 AMD64 unhandled syscall: 24 (sched_yield) +109358 fork() won't work with valgrind-3.0 SVN +109332 amd64 unhandled instruction: ADC Ev, Gv +109314 Bogus memcheck report on amd64 +108883 Crash; vg_memory.c:905 (vgPlain_init_shadow_range): + Assertion `vgPlain_defined_init_shadow_page()' failed. +108349 mincore syscall parameter checked incorrectly=20 +108059 build infrastructure: small update +107524 epoll_ctl event parameter checked on EPOLL_CTL_DEL +107123 Vex dies with unhandled instructions: 0xD9 0x31 0xF 0xAE +106841 auxmap & openGL problems +106713 SDL_Init causes valgrind to exit +106352 setcontext and makecontext not handled correctly=20 +106293 addresses beyond initial client stack allocation=20 + not checked in VALGRIND_DO_LEAK_CHECK +106283 PIE client programs are loaded at address 0 +105831 Assertion `vgPlain_defined_init_shadow_page()' failed. +105039 long run-times probably due to memory manager=20 +104797 valgrind needs to be aware of BLKGETSIZE64 +103594 unhandled instruction: FICOM +103320 Valgrind 2.4.0 fails to compile with gcc 3.4.3 and -O0 +103168 potentially memory leak in coregrind/ume.c=20 +102039 bad permissions for mapped region at address 0xB7C73680 +101881 weird assertion problem +101543 Support fadvise64 syscalls +75247 x86_64/amd64 support (the biggest "bug" we have ever fixed) + +(3.0RC1: 27 July 05, vex r1303, valgrind r4283). +(3.0.0: 3 August 05, vex r1313, valgrind r4316). + |
|
From: <sv...@va...> - 2005-08-27 17:20:56
|
Author: njn
Date: 2005-08-27 18:20:53 +0100 (Sat, 27 Aug 2005)
New Revision: 4538
Log:
Move some kernel constants to the right place.
Also reinstated SF_DEVICE, which is used to ensure we don't try and
leakcheck a page that is mapped from a device. This got lost in the
2.x-to-3.x transition, or some time after.
Modified:
trunk/coregrind/m_aspacemgr/aspacemgr.c
trunk/coregrind/m_signals.c
trunk/coregrind/pub_core_aspacemgr.h
trunk/include/vki-linux.h
trunk/include/vki-x86-linux.h
Modified: trunk/coregrind/m_aspacemgr/aspacemgr.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_aspacemgr/aspacemgr.c 2005-08-27 15:07:21 UTC (rev =
4537)
+++ trunk/coregrind/m_aspacemgr/aspacemgr.c 2005-08-27 17:20:53 UTC (rev =
4538)
@@ -851,8 +851,13 @@
if (fd !=3D -1 && (flags & SF_FILE)) {
vg_assert((off & (VKI_PAGE_SIZE-1)) =3D=3D 0);
=20
- if (VG_(fstat)(fd, &st) < 0)
+ if (VG_(fstat)(fd, &st) < 0) {
flags &=3D ~SF_FILE;
+ } else {
+ // Note unusual mapping types
+ if (VKI_S_ISCHR(st.st_mode) || VKI_S_ISBLK(st.st_mode))
+ flags |=3D SF_DEVICE;
+ }
}
=20
if ((flags & SF_FILE) && filename =3D=3D NULL && fd !=3D -1)
@@ -1180,7 +1185,8 @@
=20
for (i =3D 0; i < segments_used; i++) {
s =3D &segments[i];
- flags =3D s->flags & (SF_SHARED|SF_MMAP|SF_VALGRIND|SF_CORE|SF_STA=
CK);
+ // Note that, for example, we don't want to touch a device page.
+ flags =3D s->flags & (SF_SHARED|SF_MMAP|SF_VALGRIND|SF_CORE|SF_STA=
CK|SF_DEVICE);
if (flags !=3D SF_MMAP && flags !=3D SF_STACK && flags !=3D (SF_MM=
AP|SF_STACK))
continue;
if ((s->prot & (VKI_PROT_READ|VKI_PROT_WRITE))=20
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2005-08-27 15:07:21 UTC (rev 4537)
+++ trunk/coregrind/m_signals.c 2005-08-27 17:20:53 UTC (rev 4538)
@@ -928,7 +928,7 @@
/* If true, then this Segment may be mentioned in the core */
static Bool may_dump(const Segment *seg)
{
- return (seg->flags & SF_VALGRIND) =3D=3D 0 && VG_(is_client_addr)(seg=
->addr);
+ return (seg->flags & (SF_DEVICE|SF_VALGRIND)) =3D=3D 0 && VG_(is_clie=
nt_addr)(seg->addr);
}
=20
/* If true, then this Segment's contents will be in the core */
Modified: trunk/coregrind/pub_core_aspacemgr.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_aspacemgr.h 2005-08-27 15:07:21 UTC (rev 453=
7)
+++ trunk/coregrind/pub_core_aspacemgr.h 2005-08-27 17:20:53 UTC (rev 453=
8)
@@ -80,6 +80,7 @@
#define SF_CORE (1 << 7) // allocated by core on behalf of the clie=
nt
#define SF_VALGRIND (1 << 8) // a valgrind-internal mapping - not in cl=
ient
#define SF_CODE (1 << 9) // segment contains cached code
+#define SF_DEVICE (1 << 10) // device mapping; avoid careless touchin=
g
=20
typedef struct _Segment Segment;
=20
Modified: trunk/include/vki-linux.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/vki-linux.h 2005-08-27 15:07:21 UTC (rev 4537)
+++ trunk/include/vki-linux.h 2005-08-27 17:20:53 UTC (rev 4538)
@@ -1073,6 +1073,26 @@
// From linux-2.6.8.1/include/linux/stat.h
//----------------------------------------------------------------------
=20
+#define VKI_S_IFMT 00170000
+#define VKI_S_IFSOCK 0140000
+#define VKI_S_IFLNK 0120000
+#define VKI_S_IFREG 0100000
+#define VKI_S_IFBLK 0060000
+#define VKI_S_IFDIR 0040000
+#define VKI_S_IFCHR 0020000
+#define VKI_S_IFIFO 0010000
+#define VKI_S_ISUID 0004000
+#define VKI_S_ISGID 0002000
+#define VKI_S_ISVTX 0001000
+
+#define VKI_S_ISLNK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFLNK)
+#define VKI_S_ISREG(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFREG)
+#define VKI_S_ISDIR(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFDIR)
+#define VKI_S_ISCHR(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFCHR)
+#define VKI_S_ISBLK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFBLK)
+#define VKI_S_ISFIFO(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFIFO)
+#define VKI_S_ISSOCK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFSOCK)
+
#define VKI_S_IRUSR 00400
#define VKI_S_IWUSR 00200
=20
Modified: trunk/include/vki-x86-linux.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/vki-x86-linux.h 2005-08-27 15:07:21 UTC (rev 4537)
+++ trunk/include/vki-x86-linux.h 2005-08-27 17:20:53 UTC (rev 4538)
@@ -318,26 +318,6 @@
// From linux-2.6.8.1/include/asm-i386/stat.h
//----------------------------------------------------------------------
=20
-#define VKI_S_IFMT 00170000
-#define VKI_S_IFSOCK 0140000
-#define VKI_S_IFLNK 0120000
-#define VKI_S_IFREG 0100000
-#define VKI_S_IFBLK 0060000
-#define VKI_S_IFDIR 0040000
-#define VKI_S_IFCHR 0020000
-#define VKI_S_IFIFO 0010000
-#define VKI_S_ISUID 0004000
-#define VKI_S_ISGID 0002000
-#define VKI_S_ISVTX 0001000
-
-#define VKI_S_ISLNK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFLNK)
-#define VKI_S_ISREG(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFREG)
-#define VKI_S_ISDIR(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFDIR)
-#define VKI_S_ISCHR(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFCHR)
-#define VKI_S_ISBLK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFBLK)
-#define VKI_S_ISFIFO(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFIFO)
-#define VKI_S_ISSOCK(m) (((m) & VKI_S_IFMT) =3D=3D VKI_S_IFSOCK)
-
struct vki_stat {
unsigned long st_dev;
unsigned long st_ino;
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 17:18:56
|
Hi, In the transition from 2.x to 3.x, --weird-hacks=ioctl-mmap got disabled. In POST(sys_ioctl) it had been checked for and if was set, VG_(sync_segments)() was called. It's no longer checked in 3.x, and VG_(sync_segments)() is gone. Should it be reinstated? Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 16:57:22
|
On Sat, 27 Aug 2005, Tom Hughes wrote:
> I can't really see how we can sensibly do localtime_r - reading and
> handling the timezone database is just going to get silly.
Perhaps we can switch to showing the number of seconds elapsed since
startup. Because people might use --trace-children=yes, we'd want a
command-line arg with which you can pass a starting value for this.
Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass
--initial-time-stamp=5 to bar so that the elapsed times were in sync.
Actually, better would be to make --time-stamp take an int (or float?)
rather than be boolean, which would avoid creating a new CLO.
How's that sound? I think it satisfies the two things people use
--time-stamp for:
- recording how long an execution took (esp. for long-running programs)
- getting the relative times of events, including with --trace-children
N
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 16:52:22
|
On Sat, 27 Aug 2005, Jeroen N. Witmond wrote: > Second step was to look for tools that could transform one of the outputs > or intermediates in the current build processes in docs/. The text-based > web browser lynx does a passable job of transforming docs/html/FAQ.html > into plain text, which probably could be improved with some sed tweaks. If > you have lynx installed, try `lynx -dump docs/html/FAQ.html`. Given this > result, I gave up very soon when looking for tools to convert .fo, .pdf or > .ps to plain text. But this step still requires the installation (and > maintenance) of yet another tool. Yeah, we've looked at lynx for this before, the output requires a lot of cleaning up... > Third step is still in progress, and consists of borrowing and writing xsl > transformations to handle the job. These can then be executed using the > same tools as currently used. They should be finished Real Soon Now(TM). > I've gotten all constructs used in the FAQ to work but for the lists, but > this should be no more than a matter of plumbing. So this would be a replacement for using lynx? That would be best. It surprises me that there aren't readily available Docbook-to-text transformers, but it seems there aren't. > Just doing my small bit for a great product. (: In the next day or two I'm planning to write a list of possible projects for people who are interested in to work on, and put it on the website. Other projects like GCC have this, it seems like a good idea, especially for people who want to contribute but aren't sure where to start. There will be a range of things on it, from easy stuff that a beginner could do, to research-level problems. Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-27 15:31:31
|
> On Thu, 18 Aug 2005, Jeroen N. Witmond wrote: > >> While looking for a way to generate FAQ.txt from FAQ.xml > > Ah, great... have you worked out how to do it? > First step was to look for existing tools that convert xml/docbook to plain text. I found one that produces something that might be usable with some tailoring, but its set of required software is completely disjunct from the software now used for valgrind's documentation. The tool is docbook2txt, which is a wrapper for jw, which is part of debian package docbook-utils, and itself a wrapper for jade. For more information see <http://packages.debian.org/stable/text/docbook-utils>. Second step was to look for tools that could transform one of the outputs or intermediates in the current build processes in docs/. The text-based web browser lynx does a passable job of transforming docs/html/FAQ.html into plain text, which probably could be improved with some sed tweaks. If you have lynx installed, try `lynx -dump docs/html/FAQ.html`. Given this result, I gave up very soon when looking for tools to convert .fo, .pdf or .ps to plain text. But this step still requires the installation (and maintenance) of yet another tool. Third step is still in progress, and consists of borrowing and writing xsl transformations to handle the job. These can then be executed using the same tools as currently used. They should be finished Real Soon Now(TM). I've gotten all constructs used in the FAQ to work but for the lists, but this should be no more than a matter of plumbing. >> I noticed that in a few places in file docs/xml/FAQ.xml in valgrind >> 3.1.SVN, screens and program listings are part of the answer where they >> should be part of the question. Attached patch fixes this problem. > > I've committed the changes, thanks very much. > Just doing my small bit for a great product. Jeroen. |
|
From: Tom H. <to...@co...> - 2005-08-27 15:22:35
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> (For the curious: I replaced all glibc uses by our own implementations,
> apart from three which are non-essential and hard to do:
> localtime_r in VG_(ctime)
> ptrace in m_debugger.c
> fork in m_debugger.c.
> If anyone has enthusiasm to hack up standalone replacements, especially
> for localtime_r, please hack on!)
I've done ptrace and fork now but localtime_r is harder...
The problem is time zones and daylight savings - just breaking down
the time (ie doing gmtime) is relatively easy.
I can't really see how we can sensibly do localtime_r - reading and
handling the timezone database is just going to get silly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-08-27 15:07:23
|
Author: tom
Date: 2005-08-27 16:07:21 +0100 (Sat, 27 Aug 2005)
New Revision: 4537
Log:
Implement VG_(ptrace) and VG_(fork) and get debugger attaching going agai=
n.
Modified:
branches/ASPACEM/coregrind/m_debugger.c
branches/ASPACEM/coregrind/m_libcproc.c
branches/ASPACEM/coregrind/pub_core_libcproc.h
branches/ASPACEM/include/vki-linux.h
Modified: branches/ASPACEM/coregrind/m_debugger.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_debugger.c 2005-08-27 14:21:41 UTC (rev =
4536)
+++ branches/ASPACEM/coregrind/m_debugger.c 2005-08-27 15:07:21 UTC (rev =
4537)
@@ -32,22 +32,16 @@
#include "pub_core_threadstate.h"
#include "pub_core_debugger.h"
#include "pub_core_libcbase.h"
-#include "pub_core_libcassert.h" // For I_die_here
#include "pub_core_libcprint.h"
#include "pub_core_libcproc.h"
#include "pub_core_libcsignal.h"
#include "pub_core_options.h"
=20
-// We can remove these easily by implementing our own VG_(ptrace)() and
-// VG_(fork)().
-//#include <sys/ptrace.h>
-//#include <sys/wait.h>
-//#include <unistd.h>
+#define WIFSTOPPED(status) (((status) & 0xff) =3D=3D 0x7f)
+#define WSTOPSIG(status) (((status) & 0xff00) >> 8)
=20
static Int ptrace_setregs(Int pid, VexGuestArchState* vex)
{
- I_die_here;
-#if 0
struct vki_user_regs_struct regs;
#if defined(VGA_x86)
regs.cs =3D vex->guest_CS;
@@ -67,7 +61,7 @@
regs.eflags =3D LibVEX_GuestX86_get_eflags(vex);
regs.eip =3D vex->guest_EIP;
=20
- return ptrace(PTRACE_SETREGS, pid, NULL, ®s);
+ return VG_(ptrace)(VKI_PTRACE_SETREGS, pid, NULL, ®s);
#elif defined(VGA_amd64)
regs.rax =3D vex->guest_RAX;
regs.rbx =3D vex->guest_RBX;
@@ -88,14 +82,13 @@
regs.eflags =3D LibVEX_GuestAMD64_get_rflags(vex);
regs.rip =3D vex->guest_RIP;
=20
- return ptrace(PTRACE_SETREGS, pid, NULL, ®s);
+ return VG_(ptrace)(VKI_PTRACE_SETREGS, pid, NULL, ®s);
#elif defined(VGA_ppc32)
I_die_here;
regs.gpr[0] =3D 0; // stop compiler complaints
#else
# error Unknown arch
#endif
-#endif /* 0 */
}
=20
/* Start debugger and get it to attach to this process. Called if the
@@ -105,12 +98,10 @@
continue, quit the debugger. */
void VG_(start_debugger) ( ThreadId tid )
{
- I_die_here;
-#if 0
Int pid;
=20
- if ((pid =3D fork()) =3D=3D 0) {
- ptrace(PTRACE_TRACEME, 0, NULL, NULL);
+ if ((pid =3D VG_(fork)()) =3D=3D 0) {
+ VG_(ptrace)(VKI_PTRACE_TRACEME, 0, NULL, NULL);
VG_(kill)(VG_(getpid)(), VKI_SIGSTOP);
=20
} else if (pid > 0) {
@@ -118,10 +109,10 @@
Int res;
=20
if ((res =3D VG_(waitpid)(pid, &status, 0)) =3D=3D pid &&
- WIFSTOPPED(status) && WSTOPSIG(status) =3D=3D SIGSTOP &&
+ WIFSTOPPED(status) && WSTOPSIG(status) =3D=3D VKI_SIGSTOP &&
ptrace_setregs(pid, &(VG_(threads)[tid].arch.vex)) =3D=3D 0 &&
- VG_(kill)(pid, SIGSTOP) =3D=3D 0 &&
- ptrace(PTRACE_DETACH, pid, NULL, 0) =3D=3D 0)
+ VG_(kill)(pid, VKI_SIGSTOP) =3D=3D 0 &&
+ VG_(ptrace)(VKI_PTRACE_DETACH, pid, NULL, 0) =3D=3D 0)
{
Char pidbuf[15];
Char file[30];
@@ -177,7 +168,6 @@
VG_(kill)(pid, VKI_SIGKILL);
VG_(waitpid)(pid, &status, 0);
}
-#endif
}
=20
=20
Modified: branches/ASPACEM/coregrind/m_libcproc.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_libcproc.c 2005-08-27 14:21:41 UTC (rev =
4536)
+++ branches/ASPACEM/coregrind/m_libcproc.c 2005-08-27 15:07:21 UTC (rev =
4537)
@@ -434,6 +434,32 @@
}
=20
/* ---------------------------------------------------------------------
+ Process tracing
+ ------------------------------------------------------------------ */
+
+Int VG_(ptrace) ( Int request, Int pid, void *addr, void *data )
+{
+ SysRes res;
+ res =3D VG_(do_syscall4)(__NR_ptrace, request, pid, (UWord)addr, (UWo=
rd)data);
+ if (res.isError)
+ return -1;
+ return res.val;
+}
+
+/* ---------------------------------------------------------------------
+ Fork
+ ------------------------------------------------------------------ */
+
+Int VG_(fork) ( void )
+{
+ SysRes res;
+ res =3D VG_(do_syscall0)(__NR_fork);
+ if (res.isError)
+ return -1;
+ return res.val;
+}
+
+/* ---------------------------------------------------------------------
Timing stuff
------------------------------------------------------------------ */
=20
Modified: branches/ASPACEM/coregrind/pub_core_libcproc.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/pub_core_libcproc.h 2005-08-27 14:21:41 UT=
C (rev 4536)
+++ branches/ASPACEM/coregrind/pub_core_libcproc.h 2005-08-27 15:07:21 UT=
C (rev 4537)
@@ -76,6 +76,8 @@
extern Int VG_(poll)( struct vki_pollfd *, UInt nfds, Int timeout);
extern void VG_(nanosleep) ( struct vki_timespec * );
extern Int VG_(getgroups)( Int size, UInt* list );
+extern Int VG_(ptrace)( Int request, Int pid, void *addr, void *data );
+extern Int VG_(fork)( void );
=20
// atfork
typedef void (*vg_atfork_t)(ThreadId);
Modified: branches/ASPACEM/include/vki-linux.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/include/vki-linux.h 2005-08-27 14:21:41 UTC (rev 453=
6)
+++ branches/ASPACEM/include/vki-linux.h 2005-08-27 15:07:21 UTC (rev 453=
7)
@@ -1952,10 +1952,13 @@
// From linux-2.6.9/include/linux/ptrace.h
//----------------------------------------------------------------------
=20
+#define VKI_PTRACE_TRACEME 0
#define VKI_PTRACE_PEEKTEXT 1
#define VKI_PTRACE_PEEKDATA 2
#define VKI_PTRACE_PEEKUSR 3
=20
+#define VKI_PTRACE_DETACH 0x11
+
#endif // __VKI_LINUX_H
=20
/*--------------------------------------------------------------------*/
|
|
From: <sv...@va...> - 2005-08-27 14:21:49
|
Author: tom
Date: 2005-08-27 15:21:41 +0100 (Sat, 27 Aug 2005)
New Revision: 4536
Log:
Make sure _start provides a 16 byte aligned stack to the C code.
Modified:
branches/ASPACEM/coregrind/m_main.c
Modified: branches/ASPACEM/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_main.c 2005-08-27 13:46:23 UTC (rev 4535=
)
+++ branches/ASPACEM/coregrind/m_main.c 2005-08-27 14:21:41 UTC (rev 4536=
)
@@ -2939,7 +2939,11 @@
"\t.type _start,@function\n"
"_start:\n"
"\tmovl %esp,%eax\n"
- "\tpushl %eax\n"
+ "\tandl $~15,%esp\n" /* Make sure stack is 16 byte aligned */
+ "\tpushl %eax\n" /* Push junk to preserve alignment */
+ "\tpushl %eax\n" /* Push junk to preserve alignment */
+ "\tpushl %eax\n" /* Push junk to preserve alignment */
+ "\tpushl %eax\n" /* Pass pointer to argc to _start_in_C */
"\tcall _start_in_C\n"
"\thlt\n"
);
@@ -2948,7 +2952,8 @@
"\t.globl _start\n"
"\t.type _start,@function\n"
"_start:\n"
- "\tmovq %rsp,%rdi\n"
+ "\tmovq %rsp,%rdi\n" /* Pass pointer to argc to _start_in_C */
+ "\tandq $~15,%rsp\n" /* Make sure stack is 16 byte aligned */
"\tcall _start_in_C\n"
"\thlt\n"
);
|
|
From: <sv...@va...> - 2005-08-27 13:46:26
|
Author: sewardj Date: 2005-08-27 14:46:23 +0100 (Sat, 27 Aug 2005) New Revision: 4535 Log: Oops, forgot to reinstate building of massif. Modified: branches/ASPACEM/massif/Makefile.am Modified: branches/ASPACEM/massif/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/ASPACEM/massif/Makefile.am 2005-08-27 13:00:35 UTC (rev 4534= ) +++ branches/ASPACEM/massif/Makefile.am 2005-08-27 13:46:23 UTC (rev 4535= ) @@ -2,11 +2,9 @@ =20 SUBDIRS +=3D hp2ps =20 -val_PROGRAMS =3D vgtool_massif.so vgpreload_massif.so +val_PROGRAMS =3D vgpreload_massif.so +bin_PROGRAMS =3D valgrind_massif =20 -vgtool_massif_so_SOURCES =3D ms_main.c -vgtool_massif_so_LDFLAGS =3D -shared - vgpreload_massif_so_SOURCES =3D=20 vgpreload_massif_so_DEPENDENCIES =3D \ $(LIBREPLACEMALLOC) @@ -15,4 +13,12 @@ $(LIBREPLACEMALLOC) \ -Wl,--no-whole-archive =20 - +valgrind_massif_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a +valgrind_massif_SOURCES =3D \ + ms_main.c +valgrind_massif_LDFLAGS =3D \ + -static \ + $(top_srcdir)/coregrind/libcoregrind.a \ + -Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \ + -Wl,-T,$(top_srcdir)/valt_load_address.lds \ + -nodefaultlibs -lgcc -nostartfiles |
|
From: <sv...@va...> - 2005-08-27 13:00:39
|
Author: sewardj
Date: 2005-08-27 14:00:35 +0100 (Sat, 27 Aug 2005)
New Revision: 4534
Log:
- reenable building of none, lackey and cachegrind (static, glibc-free
of course)
- in m_main, automatically deduce the tool name from the the of the
executable name
- in m_main, ignore any --tool=3D flags as it is way too late to do=20
anything about them now :-)
Modified:
branches/ASPACEM/cachegrind/Makefile.am
branches/ASPACEM/coregrind/m_main.c
branches/ASPACEM/lackey/Makefile.am
branches/ASPACEM/none/Makefile.am
Modified: branches/ASPACEM/cachegrind/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/cachegrind/Makefile.am 2005-08-27 06:56:32 UTC (rev =
4533)
+++ branches/ASPACEM/cachegrind/Makefile.am 2005-08-27 13:00:35 UTC (rev =
4534)
@@ -9,10 +9,15 @@
=20
noinst_HEADERS =3D cg_arch.h
=20
-val_PROGRAMS =3D vgtool_cachegrind.so
+bin_PROGRAMS =3D valgrind_cachegrind
=20
-vgtool_cachegrind_so_SOURCES =3D \
+valgrind_cachegrind_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrin=
d.a
+valgrind_cachegrind_SOURCES =3D \
cg_main.c \
cg-@VG_ARCH@.c
-vgtool_cachegrind_so_LDFLAGS =3D -shared
-
+valgrind_cachegrind_LDFLAGS =3D \
+ -static \
+ $(top_srcdir)/coregrind/libcoregrind.a \
+ -Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
+ -Wl,-T,$(top_srcdir)/valt_load_address.lds \
+ -nodefaultlibs -lgcc -nostartfiles
Modified: branches/ASPACEM/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_main.c 2005-08-27 06:56:32 UTC (rev 4533=
)
+++ branches/ASPACEM/coregrind/m_main.c 2005-08-27 13:00:35 UTC (rev 4534=
)
@@ -1014,9 +1014,7 @@
load_tool__preloadpath[VKI_PATH_MAX-1] =3D 0;
*preloadpath_out =3D load_tool__preloadpath;
} else {
- VG_(printf)("valgrind: couldn't find preload file for tool %s\n",=20
- toolname);
- VG_(exit)(127);
+ *preloadpath_out =3D NULL;
}
}
=20
@@ -1255,7 +1253,8 @@
*need_help =3D 2;
=20
} else if (VG_CLO_STREQN(7, vg_argv[i], "--tool=3D")) {
- *tool =3D &vg_argv[i][7];
+ /* *tool =3D &vg_argv[i][7]; */
+ /* ignore this, since by now it is way too late to change */
=20
} else if (VG_CLO_STREQN(7, vg_argv[i], "--exec=3D")) {
*exec =3D &vg_argv[i][7];
@@ -2270,20 +2269,20 @@
=20
Int main(Int argc, HChar **argv, HChar **envp)
{
- HChar** cl_argv;
- const HChar* tool =3D "memcheck"; // default to Memcheck
- const HChar* exec =3D NULL;
- HChar* preload; /* tool-specific LD_PRELOAD .so */
- HChar** env;
- Int need_help =3D 0; // 0 =3D no, 1 =3D --help, 2 =3D =
--help-debug
- struct exeinfo info;
- ToolInfo* toolinfo =3D NULL;
- Addr client_eip;
- Addr sp_at_startup; /* client's SP at the point we
- gained control. */
- UInt* client_auxv;
- Int loglevel, i;
- struct vki_rlimit zero =3D { 0, 0 };
+ HChar** cl_argv;
+ HChar* tool =3D NULL; // will acquire tool name later
+ HChar* exec =3D NULL;
+ HChar* preload =3D NULL; /* tool-specific LD_PRELOAD .so */
+ HChar** env;
+ Int need_help =3D 0; // 0 =3D no, 1 =3D --help, 2 =3D --help=
-debug
+ struct exeinfo info;
+ ToolInfo* toolinfo =3D NULL;
+ Addr client_eip;
+ Addr sp_at_startup; /* client's SP at the point we
+ gained control. */
+ UInt* client_auxv;
+ Int loglevel, i;
+ struct vki_rlimit zero =3D { 0, 0 };
=20
//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
// Nb: startup is complex. Prerequisites are shown at every step.
@@ -2354,7 +2353,8 @@
// Look for alternative libdir =20
// p: none
//--------------------------------------------------------------
- if (0) { HChar *cp =3D VG_(getenv)(VALGRINDLIB);
+ if (0) {
+ HChar *cp =3D VG_(getenv)(VALGRINDLIB);
if (cp !=3D NULL)
VG_(libdir) =3D cp;
}
@@ -2390,6 +2390,28 @@
//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
//--------------------------------------------------------------
+ // Figure out the tool name by looking at the executable name
+ // eg /path/to/valgrind_memcheck --> memcheck
+ // p: none, except the ability to bomb out if nothing
+ // sensible can be determined
+ //--------------------------------------------------------------
+ VG_(debugLog)(1, "main", "Deducing tool name from argv[0]\n");
+ {=20
+ HChar *p0, *p1;
+ tool =3D "CANNOT_DETERMINE_TOOL_NAME";
+ /* scan to the end the the exe name */
+ p0 =3D argv[0];
+ for (p1 =3D p0; *p1; p1++)
+ ;
+ /* scan bwds to find '_' */
+ for (; p1 > p0 && *p1 !=3D '_'; p1--)
+ ;
+ if (p1 > p0 && *p1 =3D=3D '_')
+ tool =3D p1 + 1;
+ }
+ VG_(debugLog)(1, "main", "Deduced tool name =3D '%s'\n", tool);
+
+ //--------------------------------------------------------------
// With client padded out, map in tool
// p: set-libdir [for VG_(libdir)]
// p: pre_process_cmd_line_options() [for 'tool']
Modified: branches/ASPACEM/lackey/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/lackey/Makefile.am 2005-08-27 06:56:32 UTC (rev 4533=
)
+++ branches/ASPACEM/lackey/Makefile.am 2005-08-27 13:00:35 UTC (rev 4534=
)
@@ -1,7 +1,13 @@
include $(top_srcdir)/Makefile.tool.am
=20
-val_PROGRAMS =3D vgtool_lackey.so
+bin_PROGRAMS =3D valgrind_lackey
=20
-vgtool_lackey_so_SOURCES =3D lk_main.c
-vgtool_lackey_so_LDFLAGS =3D -shared
-
+valgrind_lackey_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+valgrind_lackey_SOURCES =3D \
+ lk_main.c
+valgrind_lackey_LDFLAGS =3D \
+ -static \
+ $(top_srcdir)/coregrind/libcoregrind.a \
+ -Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
+ -Wl,-T,$(top_srcdir)/valt_load_address.lds \
+ -nodefaultlibs -lgcc -nostartfiles
Modified: branches/ASPACEM/none/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/none/Makefile.am 2005-08-27 06:56:32 UTC (rev 4533)
+++ branches/ASPACEM/none/Makefile.am 2005-08-27 13:00:35 UTC (rev 4534)
@@ -1,7 +1,13 @@
include $(top_srcdir)/Makefile.tool.am
=20
-val_PROGRAMS =3D vgtool_none.so
+bin_PROGRAMS =3D valgrind_none
=20
-vgtool_none_so_SOURCES =3D nl_main.c
-vgtool_none_so_LDFLAGS =3D -shared
-
+valgrind_none_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+valgrind_none_SOURCES =3D \
+ nl_main.c
+valgrind_none_LDFLAGS =3D \
+ -static \
+ $(top_srcdir)/coregrind/libcoregrind.a \
+ -Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
+ -Wl,-T,$(top_srcdir)/valt_load_address.lds \
+ -nodefaultlibs -lgcc -nostartfiles
|
|
From: <sv...@va...> - 2005-08-27 06:56:36
|
Author: njn
Date: 2005-08-27 07:56:32 +0100 (Sat, 27 Aug 2005)
New Revision: 4533
Log:
Avoid compiler warnings.
Modified:
branches/ASPACEM/coregrind/m_main.c
Modified: branches/ASPACEM/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_main.c 2005-08-27 01:10:17 UTC (rev 4532=
)
+++ branches/ASPACEM/coregrind/m_main.c 2005-08-27 06:56:32 UTC (rev 4533=
)
@@ -2873,9 +2873,11 @@
=20
/* ---------------- Requirement 1 ---------------- */
=20
+void* memcpy(void *dest, const void *src, size_t n);
void* memcpy(void *dest, const void *src, size_t n) {
return VG_(memcpy)(dest,src,n);
}
+void* memset(void *s, int c, size_t n);
void* memset(void *s, int c, size_t n) {
return VG_(memset)(s,c,n);
}
|
|
From: <js...@ac...> - 2005-08-27 02:56:05
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-08-27 03:30:00 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 185 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2005-08-27 02:44:49
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-08-27 04:40:00 CEST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 158 tests, 17 stderr failures, 1 stdout failure ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/fprw (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stdout) cachegrind/tests/dlclose (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) |
|
From: Tom H. <to...@co...> - 2005-08-27 02:41:40
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-08-27 03:30:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 187 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-27 02:28:05
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-08-27 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 186 tests, 14 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 186 tests, 15 stderr failures, 2 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/cmpxchg8b (stdout) none/tests/x86/cmpxchg8b (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Aug 27 03:21:18 2005 --- new.short Sat Aug 27 03:27:59 2005 *************** *** 8,10 **** ! == 186 tests, 15 stderr failures, 2 stdout failures ================= memcheck/tests/addressable (stderr) --- 8,10 ---- ! == 186 tests, 14 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) *************** *** 22,27 **** none/tests/faultstatus (stderr) - none/tests/x86/cmpxchg8b (stdout) - none/tests/x86/cmpxchg8b (stderr) none/tests/x86/int (stderr) - none/tests/x86/yield (stdout) --- 22,24 ---- |