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
(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-29 22:49:14
|
Author: njn Date: 2005-08-29 23:49:11 +0100 (Mon, 29 Aug 2005) New Revision: 188 Log: wibble Modified: trunk/devel/projects.html Modified: trunk/devel/projects.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/devel/projects.html 2005-08-29 22:33:11 UTC (rev 187) +++ trunk/devel/projects.html 2005-08-29 22:49:11 UTC (rev 188) @@ -125,7 +125,7 @@ </ul> =20 <p>Fixing these gaps is not very hard, just tedious. (Added August 27, -2005)<p> +2005)</p> =20 <h3>Unit regression tests</h3> <p>The regression tests are good system-level tests, but we have almost = no unit |
|
From: Nicholas N. <nj...@cs...> - 2005-08-29 22:38:11
|
Hi, I've put a couple of new things on the Valgrind website that may be of interest. - http://www.valgrind.org/devel/platforms.html now has a description of our porting priorities for Valgrind. - http://www.valgrind.org/devel/projects.html has a list of project suggestions for anyone interested in contributing to Valgrind. It includes suggestions for Valgrind features, software infrastructure improvements (eg. regression testing) and possible research projects. Feedback and further ideas are welcome! Nick |
|
From: <sv...@va...> - 2005-08-29 22:33:16
|
Author: njn Date: 2005-08-29 23:33:11 +0100 (Mon, 29 Aug 2005) New Revision: 187 Log: tweaks Modified: trunk/devel/projects.html trunk/support/contributing.html Modified: trunk/devel/projects.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/devel/projects.html 2005-08-29 22:31:00 UTC (rev 186) +++ trunk/devel/projects.html 2005-08-29 22:33:11 UTC (rev 187) @@ -79,10 +79,10 @@ but they are not free.</p></li> =20 <li><p>Artificial programs that stress performance-critical subsystems. - For example http://bugs.kde.org/show_bug.cgi?id=3D105039 has an exampl= e - program that does many malloc and free calls, and has many heap blocks - live at one time. This exposed a performance bug in Valgrind's heap - allocator.</p></li> + For example <a href=3D"http://bugs.kde.org/show_bug.cgi?id=3D105039">b= ug + report #105039</a> has an example program that does many malloc and + free calls, and has many heap blocks live at one time. This exposed a + performance bug in Valgrind's heap allocator.</p></li> </ol> =20 <p>The scripts in nightly/ for doing the nightly regression tests would = be the Modified: trunk/support/contributing.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/support/contributing.html 2005-08-29 22:31:00 UTC (rev 186) +++ trunk/support/contributing.html 2005-08-29 22:33:11 UTC (rev 187) @@ -15,7 +15,7 @@ patches that help in this respect are welcome. Please send them to the <?php echo vglink( 'vgdevel' ); ?> list.</p> =20 -<h3>Software Infrastructure and Code</h3> +<h3>Software Infrastructure, Code and Research</h3> If you are interested in writing code for Valgrind itself or its infrastructure, or doing research with it, please consult our <a href=3D"/devel/projects.html">project suggestions</a> page. |
|
From: <sv...@va...> - 2005-08-29 22:31:02
|
Author: njn
Date: 2005-08-29 23:31:00 +0100 (Mon, 29 Aug 2005)
New Revision: 186
Log:
whoops
Modified:
trunk/php/menu.php
Modified: trunk/php/menu.php
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/php/menu.php 2005-08-29 22:30:32 UTC (rev 185)
+++ trunk/php/menu.php 2005-08-29 22:31:00 UTC (rev 186)
@@ -35,8 +35,8 @@
$devel =3D array(
array( 'url'=3D>'platforms.html', 'tag'=3D>'Supported Platforms' ),
array( 'url'=3D>'cvs_svn.html', 'tag'=3D>'SVN Repos' ),
- array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' )
- array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )*=
/
+ array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' ),
+ array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )
/*array( 'url'=3D>'consultants.html', 'tag'=3D>'Commercial Support' )=
*/
);
=20
|
|
From: <sv...@va...> - 2005-08-29 22:30:36
|
Author: njn Date: 2005-08-29 23:30:32 +0100 (Mon, 29 Aug 2005) New Revision: 185 Log: Added a "project suggestions" page. Added: trunk/devel/projects.html Modified: trunk/php/menu.php trunk/support/contributing.html Added: trunk/devel/projects.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/devel/projects.html 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/devel/projects.html 2005-08-29 22:30:32 UTC (rev 185) @@ -0,0 +1,417 @@ + +<h1>Project Suggestions</h1> + +<p>This page gives a list of Valgrind projects that people might like to +try. They range from quite easy hacking projects to research-level +problems. If you plan to try one of these projects, you should +subscribe to <?php echo vglink( 'vgdevel' ); ?> list, and also write to +it to let us know you are doing the project, and you can ask questions +there also.</p> + +<p>Please note that we are very conservative about adding new features. +Only features that are useful to many users, and that do not adversely +affect the maintainability or correctness of the code base in adverse +ways are likely to be accepted. If you want to implement a feature not +mentioned on the following list, please ask on the valgrind-developers +list if it is likely to be incorporated before starting.</p> + +<p>Also, please understand that there is no guarantee that code you +write will be incorporated into Valgrind. It depends on a number of +factors: how well written it is, how important are the issues it +addresses, how does it affect the code base's structure, and so on. +Such is the nature of all free software projects. However, if you +consistently submit high quality patches, you may be granted write +access to the repository. This is how most of the current developers got +involved with Valgrind.</p> + +<h2>Software Infrastructure</h2> + +<h3>Profiling Valgrind</h3> +<p>We haven't had a good way to profile Valgrind for something like 2 ye= ars. +If we could find a way to profile Valgrind, there would certainly be som= e +easy speed-ups to find. That would make everybody happier!</p> + +<p>Valgrind used to have a tick-based profiler. A timer was set up to s= end +SIGALRM 100 times per second, and every time it was caught Valgrind woul= d +record where in its code it was. This gave a good view of which parts o= f +the code were responsible for the most amount of runtime. The code for = this +is still there (see coregrind/m_profile.c) but it hasn't worked for a lo= ng +time. If you activate it (set VG_DO_PROFILING in include/pub_tool_profi= le.h, +recompile, and use --profile=3Dyes) Valgrind bombs due to signal issues. +Also, this relies on the glibc function setitimer(), and we are in the +process of removing all dependencies on glibc.</p> + +<p>Neither gcov nor gprof work with Valgrind, basically because Valgrind= does +weird stuff that they cannot handle. Perhaps another tool (OProfile?) w= ould +be appropriate.</p> + +<p>Using Cachegrind is a possibility, although Valgrind's support for ru= nning +itself is very flaky at the moment. Improving this support would also l= et +us run Valgrind itself under Memcheck.</p> + +<p>Or if anyone knows how to get the tick-based profiler working again +without relying on glibc functions, that would be a good start. (Added +August 27, 2005)</p> + + +<h3>Performance regression testing</h3> +<p>We currently have some scripts to run the regression tests nightly on +a range of machines. This is very useful for spotting correctness +regressions. Equally useful would be a system for spotting performance +regressions (or improvements).</p> + +<p>This would involve running the Valgrind tools on a given suite of +programs, and recording how long they take to run. Or, perhaps better +would be recording how much slower than normal the programs run under +Valgrind; that metric would be more robust if the compiler or system +libraries on the test machine changed.</p> + +<p>The nightly measurements should be kept and ideally there would be a +system for producing graphs that show the performance changes over time. +You'd have to specify somehow where the previous measurements would be +stored, perhaps that would be a command line argument to the script.</p> + +<p>Choosing the programs for the test suite would be challenging. +Ideally we'd have a mix of two kinds of programs:</p> + +<ol> +<li><p>Real programs. Ones like the SPEC2000 benchmarks would be ideal, + but they are not free.</p></li> + =20 +<li><p>Artificial programs that stress performance-critical subsystems. + For example http://bugs.kde.org/show_bug.cgi?id=3D105039 has an exampl= e + program that does many malloc and free calls, and has many heap blocks + live at one time. This exposed a performance bug in Valgrind's heap + allocator.</p></li> +</ol> + +<p>The scripts in nightly/ for doing the nightly regression tests would = be the +right place to start on this. (Added August 27, 2005)</p> + + +<h3>Regression test brittleness</h3> +<p>Valgrind's regression test suite (run with "make regtest") is extreme= ly +useful. The scripts in nightly/ are used on various test machines to +determine if regressions are introduced. Unfortunately, some of the tes= ts +are too brittle -- they fail on some machines because of slight +configuration differences. On the eight test machines we use, we see up= to +about 10 or 15 failures that should not happen due to these +differences.</p> + +<p>Improving things will require either additional expected output files= (the +*.stderr.exp* and *.stdout.exp* files in the tests/ directories), or mor= e +clever output filters (the filters have names like filter_stderr). If y= ou +attempt to improve the filters, you should be careful not to remove so m= uch +information that the test becomes weaker. (Added August 27, 2005)</p> + + +<h3>Regression test gaps</h3> +<p>The regression tests are great, but they have some gaps. For +example:</p> + +<ul> +<li><p>The auto-generated insn*.c tests in none/tests/x86/ are great: + they test almost all the x86 instructions. It would be great to have + equally comprehensive tests for the other architectures supported + (AMD64, PPC32).</p></li> + +<li><p> The test memcheck/tests/x86/scalar.c is a very thorough test for + Memcheck's checking of system call arguments. We would like similar + tests for the other platforms (AMD64, PPC32).</p></li> + +<li><p> Memcheck and Nulgrind (aka "none") have a good number of tests + each. The other tools have very few. Adding more salient tests would + be useful.</p></li> +</ul> + +<p>Fixing these gaps is not very hard, just tedious. (Added August 27, +2005)<p> + +<h3>Unit regression tests</h3> +<p>The regression tests are good system-level tests, but we have almost = no unit +testing, which is bad. We would like to pull out individual Valgrind +modules into test harnesses. These can then be tested like normal progr= ams, +using normal testing tools, such as gcov (for test coverage) and Valgrin= d +itself.</p> + +<p>The test memcheck/tests/oset_test.c is one unit test we have. It tes= ts the +m_oset module. It uses some preprocessing hacks to replace calls to +Valgrind-internal functions with calls to the standard versions, eg. cal= ling +printf() instead of VG_(printf)(). memcheck/tests/vgtest_ume.c is anoth= er +one, although it has some oddities that make it not such a good +example.</p> + +<p>(Note that when this test runs, the Valgrind built in the tree is act= ually +running and testing part of its own code! Which is quirky but fine in +practice.)</p> + +<p>Some modules will be more amenable to this approach than others; the = fewer +other modules a module depends on, the easier it is. m_oset is a case i= n +point, as it only imports 5 pub_core_* header files. Other files in +coregrind/ that would be good candidates include:</p> + +<ul> +<li>m_debuglog.c</li> +<li>m_execontext.c</li> +<li>m_hashtable.c (the test would be very similar to + m_oset.c's),</li> +<li>m_libc{assert,base,file,mman,print,proc,signal}.c</li> +<li>m_mallocfree.c (a test for this would be particularly + helpful)</li> +<li>m_stacktrace.c</li> +<li>m_syscall.c</li> +</ul> + +<p>The following would be more challenging, but perhaps still +doable:</p> + +<ul> +<li>m_stacks.c</li> +<li>m_translate.c</li> +<li>m_transtab.c</li> +<li>m_ume.c (maybe use vgtest_ume.c as a starting point, but beware + that this file will change signficantly soon)</li> +</ul> + +<p>As well as redirecting Valgrind-internal functions to glibc +equivalents, stubs for various functions would need to be written for +many of these, as is standard for unit tests.</p> + +<p>The coverage (as measured by gcov) should be as high as possible. +The coverage for m_oset.c's test is over 99%.</p> + +<p>Just fitting these tests into the existing regression test framework +means that they will only be run under Valgrind. It might also be +worthwhile to introduce a new type of regression test that should also +be run natively; this native run could use gcov to determine the test +coverage. (Added August 27, 2005)</p> + + +<h2>Coding</h2> + +<h3>Bug fixes</h3> +<p>Bug fixes are always welcome. Please consult the Bugzilla page for t= he +current bug list. Bear in mind that choosing the right bugs to fix is a= n +art, and it may be worth consulting the developers list before throwing = a +lot of effort at fixing something very obscure. Patches should be submit= ted +to the relevant Bugzilla page. (Added August 27, 2005)</p> + + +<h3>Printing floating point values</h3> +<p>Valgrind's VG_(printf)() function (in coregrind/m_debuglog.c) does +not support the %f qualifier for printing floating point numbers. In +several places (eg. in VG_(percentify)() in coregrind/m_libcprint.c) the +code prints floating point numbers in an ad hoc way. Support for the %f +qualifier would simplify things. The support probably wouldn't need to +worry about a lot of the obscure corner cases (eg. NaNs, infinities, +denormals) that complicate all things related to floating point +numbers. (Added August 27, 2005)</p> + + +<h3>Updating the C++ demangler</h3> +<p>Valgrind's C++ demangler was copied almost verbatim from GNU binutils +about 4 years ago. We have heard of one or two cases where it is +failing to demangle some symbols; it's possible that new demangling +cases have been introduced since then. It would be useful if someone +checked that the demangler is up-to-date, and fixed it if not. The +relevant Valgrind files are coregrind/m_demangle/*.c. This would be a +relatively easy project, at the same time being of benefit to a large +proportion of the Valgrind user base. (Added August 27, 2005)</p> + + +<h3>Core dumping</h3> +<p>Valgrind 2.4.0 could produce useful core dumps. This functionality +was disabled in the transition to 3.0.0. It would be useful to have it +back. This requires factoring out the x86/Linux-specific parts +suitably. The old code is in m_coredump.c, entirely commented out. +This would be fairly easy, it just requires looking up the ELF +documentation to understand how core dumps are structured. (Added Augus= t +27, 2005)</p> + + +<h3>Supporting custom allocators</h3> +<p>Valgrind has two client requests, VALGRIND_MALLOCLIKE_BLOCK and +VALGRIND_FREELIKE_BLOCK that are intended to support custom allocators. +But they don't work very well. In particular, if you try to hand out +pieces of memory that came from a malloc() call, they don't work. You +could write new requests (give them different names) that avoid these +problems. You should test it with one or more real custom allocators to +make sure it suffices; the problems with the existing requests stem from +the fact that they weren't tested in this way. The *MEMPOOL* client +requests are there for pool-based custom allocators. Looking at them +may be instructive. This is a fairly straightforward project. (Added +August 27, 2005)</p> + + +<h3>Addrcheck and/or compressed V bit representation</h3> +<p>Memcheck more than doubles the amount of memory a program uses, due +to its V bits. Addrcheck only increases memory by 1/8th. However, +Addrcheck has not yet been converted from the 2.x to the 3.x line. The +main issue is converting it to be 64-bit clean, particularly the shadow +memory. Also, Valgrind's structure has been rearranged a lot since 2.x +and Addrcheck has bit-rotted somewhat because of this. Getting +Addrcheck working is fairly straightforward, although it would require a +good understanding of how shadow memory works.</p> + +<p>An alternative is to make Memcheck use less memory. It shadows each +byte of memory with 8 V bits and 1 A bit. However, the 8 V bits are +almost always either all 0 or all 1, so there is great potential for +compressing the representation. Each byte could be shadowed by 2 bits, +with the following meanings:</p> + +<ul> +<li>00: unaddressable (but treated as defined; see the Memcheck + USENIX paper for details why);</li> +<li>01: addressable but all 8 bits are undefined;</li> +<li>10: addressable and all 8 bits are defined;</li> +<li>11: something else.</li> +</ul> + +<p>A secondary table would be needed for the "something else" case; it +would map memory addresses to V-bit/A-bit values. The OSet structure +(see include/pub_tool_oset.h) would be good for this.</p> + +<p>Hopefully this can be implemented with a negligible slow-down, since +the "something else" case is so rare. And the big advantage is the +large reduction in the amount of address space used, which is +particularly important on 32-bit machines such as x86. If compressed V +bits work well, we could probably get rid of Addrcheck altogether, since +the reduced memory usage is the main advantage it has over Memcheck. (A= dded +August 27, 2005)</p> + + +<h3>Preserving debugging information</h3> +<p>Currently, Valgrind unloads debugging information for shared objects +when they are unloaded with dlclose(). If the shared object has a +memory leak, the stack trace for Memcheck's error message at termination +will be missing entries, which makes fixing the leak difficult. This is +described in <a href=3D"http://bugs.kde.org/show_bug.cgi?id=3D79362">bug +report #79362</a>.</p> + +<p>One way to fix this would be to change things so that Valgrind +records source-level information for stack traces, rather than code +addresses. It is not entirely clear how to do this in a way that avoids +unnecessary debug information lookups, and nor how to avoid increasing +the amount of memory used. An implementation would help clarify the +problem and show if this approach is feasible. This project is of +intermediate difficulty. (Added August 27, 2005)</p> + + +<h3>Ports to new platforms</h3> +<p>If you are interested in porting Valgrind to a new platform, please +read <a href=3D"/devel/platforms.html#porting_plans">porting priorities +statement</a>. Note that porting is a big task and requires a great +deal of knowledge about the targeted operating system and architecture. +(Added August 27, 2005)</p> + + +<h2>Research</h2> + +<h3>Memcheck V-bit verification</h3> +<p>Nobody has ever properly tested how reliably Memcheck tracks +definedness (V bits) through complicated integer operations, nor whether +all shadow memory load/store operations work right when you take into +account all permutations of operation size, alignment and endianness. +It would be useful to have a more formal idea of the properties of the +scheme. (An interesting case: there are two forms of V bit computation +for addition, an exact one that Memcheck uses in certain crucial cases, +and an approximation one that is used most of the time.)</p> + +<p>Cryptographic algorithms -- which do a lot of bit twiddling and have +very long chains of dependent computations -- might be a good starting +point (you could run a crypto algorithm with completely defined input, +then run it gain with one undefined bit in the input, etc). The +Memcheck USENIX paper describes Memcheck's operations in some detail. +This could be a relatively easy, yet interesting, starter project, +suitable for an advanced project for an undergraduate student. (Added +August 27, 2005)</p> + + +<h3>Characterising the kernel interface</h3> +<p>The interface between Valgrind and the OS kernel is complex and +important. System calls, signals, threads and memory layout are all +involved. A document that carefully described all the interactions +would be very useful, and might lead to improvements in the +implementation. This would not be easy, but would be a great way to +learn about OS kernels and Valgrind's internals. (Added August 27, 2005.= )</p> + + +<h3>Identifying root causes of undefined value errors</h3> +<p>Memcheck's undefined value errors report the use of undefined values +at the point at which they could affect the program's behaviour. This +is often far from the root cause of the error, which often makes fixing +these errors challenging. The Memcheck USENIX paper has lots more +information about this.</p> + +<p>Typically the root cause is forgetting to initialise a piece of +memory such as a field in a struct. Some errors have more than one root +cause. If you could associate extra metadata with each undefined value +that identifies one of its root causes, better undefined error messages +would be possible. The hard part is maintaining that extra metadata for +all undefined value errors without taking a large performance hit. +We're not convinced it's even possible, but we'd love to be proven +wrong. A solution to this problem would be publishable. (Added August = 27, +2005)</p> + + +<h3>Cryptographic snooping</h3> +<p>Since a Valgrind tool can see every operation performed by a program, +it is conceivable that a tool might be able to analyse some kind of +cryptographic program as it runs to extract certain secret information, +such as a key. This may not be true at all, but it's an intriguing +thought. Assuming there is some truth to it, this might make a good +research project for an honours undergraduate or Masters student, and +could well be publishable if done well. (Added August 27, 2005)</p> + + +<h3>Detecting dangerous floating point inaccuracies</h3> +<p>Floating point arithmetic is difficult to get right. It is easy to +write programs whose outcome depend on incorrect assumptions about +levels of precision. One could imagine a tool that tracks this +precision somehow, eg. by tracking each floating point value with a +plus/minus, and then complains if the program does an operation that +relies on more precision than is present.</p> + +<p>The exact details of how this would work remain unclear. It would +require a good knowledge of how floating point arithmetic works. Also, +Vex only provides 64-bit floating point accuracy, when x86 machines +provide 80-bit floating point values; this would complicate things +further.</p> + +<p>This is a challenging project that might be suitable for part of a +Masters or PhD project. It would definitely be publishable if done +well. (Added August 27, 2005)</p> + + +<h3>A better memory profiler</h3> +<p>Many memory profilers exist that can tell you how much memory your +program uses; the Valgrind tool Massif is one example. Other profilers +can tell you about the cache utilisation of a program; Cachegrind is an +example.</p> + +<p>What other kinds of information about memory use might be useful? +How else does memory use affect program performance? Perhaps measuring +memory bandwidth use in some way would be useful -- does the program +access memory in an even fashion, or is it bursty? When one part of a +program writes values in memory and another part reads them, that area +of memory can be thought of as a communication channel between the two +fragments of code. Is it possible to construct a tool which measures +these through-memory communication rates between parts of a program?</p> + +<p>Can a tool identify inefficient uses of memory, such as copying +values around unnecessarily? Perhaps a tool that measures page faults +and helps programmers avoid them would be useful.</p> + +<p>The first step is to identify what information a programmer would +like to know to improve a program's memory usage. This is harder than +it sounds. Analysing large programs that use memory intensively would +be a good starting point. The next step is to work out how a tool can +provide this information, or a good approximation of it, reasonably +efficiently.</p> + +<p>This is all quite speculative, but I think there is a new kind of +memory profiler waiting to be invented, and Valgrind would provide an +excellent platform for developing it. These questions could form part +of a Masters or PhD project. It would certainly be publishable if done +well. (Added August 27, 2005)</p> + Modified: trunk/php/menu.php =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/php/menu.php 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/php/menu.php 2005-08-29 22:30:32 UTC (rev 185) @@ -36,6 +36,7 @@ array( 'url'=3D>'platforms.html', 'tag'=3D>'Supported Platforms' ), array( 'url'=3D>'cvs_svn.html', 'tag'=3D>'SVN Repos' ), array( 'url'=3D>'guis.html', 'tag'=3D>'Front Ends / GUIs' ) + array( 'url'=3D>'projects.html', 'tag'=3D>'Project Suggestions' )*= / /*array( 'url'=3D>'consultants.html', 'tag'=3D>'Commercial Support' )= */ ); =20 Modified: trunk/support/contributing.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/support/contributing.html 2005-08-29 22:30:12 UTC (rev 184) +++ trunk/support/contributing.html 2005-08-29 22:30:32 UTC (rev 185) @@ -10,48 +10,16 @@ about writing good bug reports. Small sample programs that exhibit a bu= g are particularly helpful.</p> =20 -<h3>Testing</h3> -<p>If you can regularly test Valgrind on a range of different systems, t= hat -can be very helpful. Please contact the <?php echo vglink( 'vgdevel' ); = ?>=20 -list for more information.</p> - <h3>Documentation</h3> </p>Valgrind's documentation is not always kept up to date. Any documen= tation patches that help in this respect are welcome. Please send them to the <?php echo vglink( 'vgdevel' ); ?> list.</p> =20 -<h3>Code</h3> -<p>If you want to contribute new code to Valgrind, you should subscribe = to -the <?php echo vglink( 'vgdevel' ); ?> list.</p> +<h3>Software Infrastructure and Code</h3> +If you are interested in writing code for Valgrind itself or its +infrastructure, or doing research with it, please consult our +<a href=3D"/devel/projects.html">project suggestions</a> page. =20 -<p>There are various kinds of code you can contribute.</p> -<ul> -<li>Bug fixes are always welcome. Please consult the Bugzilla page for = the - current bug list. Patches should be submitted to the relevant Bugzi= lla - page.</li> - -<li>Ports to new platforms are also welcome. Note that porting is a big - task, and so it is worth asking on the - <?php echo vglink( 'vgdevel' ); ?> list - first if anyone else is working on a port to your chosen platform. - Ports require a very good knowledge of the platform you are porting = to. - Ports to widely used platforms are preferable.</li> - -<li>We are very conservative about adding new features. Only features - that are useful to many users, and that do not affect the code base = in - adverse ways are likely to be accepted. If you want to add a featur= e, - it is worth asking on the <?php echo vglink( 'vgdevel' ); ?> list if= it - is likely to be incorporated before starting.</li> -</ul> - -<p>Please understand that there is no guarantee that code you write will= be -incorporated into Valgrind. It depends on a number of factors: how well -written it is, how important are the issues it addresses, how does it af= fect -the code base's structure, and so on. Such is the nature of all free -software projects. However, if you consistently submit high quality -patches, you may be granted write access to the repository. This is how -most of the current developers got involved with Valgrind.</p> - <h3>Money</h3> <p>Donations are welcome, large or small. They help pay day-to-day running costs, such as bandwidth, web-hosting, electricity, and hardware |
|
From: <sv...@va...> - 2005-08-29 22:30:14
|
Author: njn Date: 2005-08-29 23:30:12 +0100 (Mon, 29 Aug 2005) New Revision: 184 Log: wibble Modified: trunk/info/about.html Modified: trunk/info/about.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/about.html 2005-08-29 08:09:05 UTC (rev 183) +++ trunk/info/about.html 2005-08-29 22:30:12 UTC (rev 184) @@ -113,11 +113,10 @@ more than make up for it.</p> =20 =20 -<h2>When to use Valgrind?</h2> +<h2>When should you use Valgrind?</h2> =20 -<p>When should you use Valgrind tools? It depends on your exact -needs. Here are some examples of when people use Valgrind's -error-finding tools.</p> +<p>It depends on your exact needs. Here are some examples of when +people use Valgrind's error-finding tools.</p> =20 <ul> =20 |
|
From: <sv...@va...> - 2005-08-29 22:24:22
|
Author: njn Date: 2005-08-29 23:24:20 +0100 (Mon, 29 Aug 2005) New Revision: 4572 Log: minor things Modified: trunk/docs/internals/3_0_BUGSTATUS.txt trunk/docs/internals/release-HOWTO.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-29 22:21:36 UTC (rev 4= 571) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-29 22:24:20 UTC (rev 4= 572) @@ -334,8 +334,13 @@ FIXED-TRUNK: TODO... partial(vg:4473) FIXED-30BRANCH: TODO =20 +---------------------------------------------------------------- +n-i-bz Jeroen's XML-to-text FAQ.xml translator =20 +FIXED-TRUNK: TODO +FIXED-30BRANCH: TODO =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Bugs of note not targeted for any particular release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Modified: trunk/docs/internals/release-HOWTO.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/release-HOWTO.txt 2005-08-29 22:21:36 UTC (rev 4= 571) +++ trunk/docs/internals/release-HOWTO.txt 2005-08-29 22:24:20 UTC (rev 4= 572) @@ -103,6 +103,8 @@ - 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. =20 +- Add a new section to docs/internals/X_Y_BUGSTATUS.txt. + - Announce the release: - Email valgrind-users, valgrind-developers, and valgrind-announce. - Email Linux Weekly News. |
|
From: <sv...@va...> - 2005-08-29 22:21:39
|
Author: njn Date: 2005-08-29 23:21:36 +0100 (Mon, 29 Aug 2005) New Revision: 4571 Log: Completely restructured this file (don't bother trying to read the diff). It's now laid out according to which release(s) a bug is targeted for, ie. which release(s) we want to fix it by. Eg. 3.0.1 and 3.1.0, or 3.1.0 only. This is more useful than grouping the bugs by when they were reported. 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-29 13:45:48 UTC (rev 4= 570) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-29 22:21:36 UTC (rev 4= 571) @@ -1,462 +1,392 @@ +nb: "n-i-bz" =3D=3D "not in Bugzilla" =20 ------------------------------------------------------------------------- ---- Bugs known prior to 3.0.0 --- ------------------------------------------------------------------------- - -x86 INT/INT3 - -Not started. Seems low priority. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 only = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +109861 amd64 hangs at startup +110301 ditto =20 -87263 x86 segment stuff +Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel +not liking large mmap/munmap requests. =20 -Not started. Seems low priority. +FIXED-TRUNK: TODO (background hacking is in progress) =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +109323 ppc32: dispatch.S uses Altivec insn, which doesn't work on POWER= .=20 =20 -88116 x86 enter variants assert +Should fix for 3.1. Any fix would be similar to that for 110274. =20 -Not started. Seems low priority. +FIXED-TRUNK: TODO =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +109345 ppc32 ptrace patch available should be applied =20 -96542 x86 16-bit pop insns +FIXED-TRUNK: TODO =20 -Not started. Seems low priority. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110183 tail of page with _end =20 -109861 amd64 hangs at startup -110301 ditto +Could be a problem for glibc developers. Consider fixing. =20 -Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel -not liking large mmap/munmap requests. +FIXED-TRUNK: TODO? =20 -FIXED-TRUNK: no (background hacking is in progress) -FIXED-30BRANCH: won't (3.1 fix only) - ---------------------------------------------------------------- +110204 fmemopen false +ve =20 -109313 x86 cmpxchg8b -110505 ditto +Seems low priority. =20 -This ought to be fixed for 3.0.1. +FIXED-TRUNK: TODO? =20 -FIXED-TRUNK: done(1331, 4390 contains regtest=20 - + mistaken commit of this file) -FIXED-30BRANCH: done(1337) - ---------------------------------------------------------------- +110205 sigcancel unwind fails =20 -109323 ppc32: dispatch.S uses Altivec insn, which doesn't work on POWER.= =20 +Tom is considering this. It would be nice to fix it for 3.1 but +status currently unclear. =20 -Should fix for 3.1. Any fix would be similar to that for 110274. +FIXED-TRUNK: vex:1320 - vex impl of sysenter + vg:4337 - minimal Valgrind-side; does not do anything =20 -FIXED-TRUNK: TODO -FIXED-30BRANCH: won't (3.1 fix only) - ---------------------------------------------------------------- +110536 Valgrind crashes when trying to realloc memory =20 -109345 ppc32 ptrace patch available should be applied +Uninvestigated. =20 FIXED-TRUNK: TODO -FIXED-30BRANCH: won't (3.1 fix only) =20 ---------------------------------------------------------------- +n-i-bz Give more info about seginfo dropping. =20 -CrispinF x86 %eflags.ac problem +FIXED-TRUNK: vg:4425 =20 -FIXED-TRUNK: yes (1319/4334) -FIXED-30BRANCH: yes (1326, and 4334 was copied across as part of 4364) =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 and 3.0.1 = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +101204 noisy warning =20 -Give more info about seginfo dropping. +FIXED-TRUNK: vg:4511 +FIXED-30BRANCH: vg:4561 =20 -FIXED-TRUNK: yes (4425) -FIXED-30BRANCH: no - ------------------------------------------------------------------------- ---- Bugs reported after 3.0.0 shipped --- ------------------------------------------------------------------------- - -110102 dis_op2_E_G(amd64) - -FIXED-TRUNK: yes (1318) -FIXED-30BRANCH: yes (1325) - ---------------------------------------------------------------- +109313 x86 cmpxchg8b =20 -110183 tail of page with _end +FIXED-TRUNK: vex:1331, vg:4390 contains regtest=20 + + mistaken commit of this file) +FIXED-30BRANCH: vex:1337 =20 -Could be a problem for glibc developers. Consider fixing. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110102 dis_op2_E_G(amd64) =20 -110201 x86 FXTRACT +FIXED-TRUNK: vex:1318 +FIXED-30BRANCH: vex:1325 =20 -Could fix if important. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- - 110202 x86 sys_waitpid(#286) =20 -FIXED-TRUNK: fixed(r4329) -FIXED-30BRANCH: fixed(r4332) +FIXED-TRUNK: vg:4329 +FIXED-30BRANCH: vg:4332 =20 ---------------------------------------------------------------- - 110203 clock_getres(,0) =20 -FIXED-TRUNK: fixed(r4328) -FIXED-30BRANCH: fixed(r4332) +FIXED-TRUNK: vg:4328 +FIXED-30BRANCH: vg:4332 =20 ---------------------------------------------------------------- +110208 execve fail wrong retval =20 -110204 fmemopen false +ve +FIXED-TRUNK: vg:4330 +FIXED-30BRANCH: vg:4332 =20 -Seems low priority. +---------------------------------------------------------------- +110274 SSE1 now mandatory for x86 =20 -FIXED-TRUNK: no -FIXED-30BRANCH: no +FIXED-TRUNK: vex:1321, vg:4339 +FIXED-30BRANCH: vex:1327, vg:4374 =20 ---------------------------------------------------------------- +110388 amd64 0xDD 0xD1 =20 -110205 sigcancel unwind fails +FIXED-TRUNK: vex:1322 +FIXED-30BRANCH: vex:1328 =20 -Tom is considering this. It would be nice to fix it for 3.1 but -status currently unclear. +---------------------------------------------------------------- +110464 amd64 0xDC 0x1D FCOMP =20 -FIXED-TRUNK: 1320 - vex impl of sysenter - 4337 - minimal Valgrind-side; does not do anything -FIXED-30BRANCH:=20 +FIXED-TRUNK: vex:1323 +FIXED-30BRANCH: vex:1329 =20 ---------------------------------------------------------------- +110478 amd64 0xF 0xD PREFETCH =20 -110207 mpn accuracy +FIXED-TRUNK: vex:1324 +FIXED-30BRANCH: vex:1330 =20 -Can't be easily fixed (x86 rounding/precision problem) -+ not convinced it's a big problem - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110591 amd64: rdtsc not implemented properly =20 -110208 execve fail wrong retval +(Also afflicts x86) =20 -FIXED-TRUNK: yes (r4330) -FIXED-30BRANCH: yes (r4332) +FIXED-TRUNK: vex:1344 (x86), vex:1346 (amd64). +FIXED-30BRANCH: vex:1354 (x86), vex:1355 (amd64). =20 ---------------------------------------------------------------- +110652 AMD64 valgrind crashes on cwtd instruction =20 -110209 --show-emwarns misses some +FIXED-TRUNK: vex:1333 +FIXED-30BRANCH: vex:1335 =20 -Tom says: The math/test-fenv.c file in the glibc source is the code in -question and I can reproduce it with that code. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction =20 -110240 x86 FP differences +FIXED-TRUNK: vex:1334 +FIXED-30BRANCH: vex:1336 =20 -really is the same as 110207; same comments apply - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba =20 -110274 SSE1 now mandatory for x86 +FIXED-TRUNK: vg:4386 +FIXED-30BRANCH: vg:4395 =20 -FIXED-TRUNK: yes(1321/4339) -FIXED-30BRANCH: yes(1327/4374) - ---------------------------------------------------------------- +110657 Small test fixes =20 -110388 amd64 0xDD 0xD1 +(1) Filter out L3 cache warning messages causing problems +(2) Stop tests/mq failing on 2.4 kernels =20 -FIXED-TRUNK: yes(1322) -FIXED-30BRANCH: yes(1328) +I suppose it would be good to apply these. They seem low risk. =20 +FIXED-TRUNK: vg:4429 +FIXED-30BRANCH: vg:4458 + ---------------------------------------------------------------- +110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) =20 -110464 amd64 0xDC 0x1D FCOMP +FIXED-TRUNK: vex:1332 +FIXED-30BRANCH: vex:1338 =20 -FIXED-TRUNK: yes(1323) -FIXED-30BRANCH: yes(1329) - ---------------------------------------------------------------- +110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) =20 -110478 amd64 0xF 0xD PREFETCH +FIXED-TRUNK: vex:1349 +FIXED-30BRANCH: vex:1356 =20 -FIXED-TRUNK: yes(1324) -FIXED-30BRANCH: yes(1330) - ---------------------------------------------------------------- +110830 configuring with --host fails to build 32 bit on 64 bit target =20 -XML <unique> printing wrong +FIXED-TRUNK: vg:4442 +FIXED-30BRANCH: vg:4459 =20 -FIXED-TRUNK: 4355,4357,4358 -FIXED-30BRANCH: 4585 - ---------------------------------------------------------------- +110875 Assertion when execve fails =20 -Dirk r4359 (amd64 syscalls from trunk) +FIXED-TRUNK: vg:4435 +FIXED-30BRANCH: vg:4457 =20 -FIXED-TRUNK: =20 -FIXED-30BRANCH: done(4359) - ---------------------------------------------------------------- +110898 opteron instructions missing: btq sbbq btsq btrq bsfq =20 -Dirk r4360 (upd email addrs from trunk) +FIXED-TRUNK: vex:1352 +FIXED-30BRANCH: vex:1357 =20 -FIXED-TRUNK: =20 -FIXED-30BRANCH: done(4360) - ---------------------------------------------------------------- +110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) =20 -110536/7/8/9/40 Valgrind crashes when trying to realloc memory +FIXED-TRUNK: vex:1343 +FIXED-30BRANCH: vex:1358 =20 -Uninvestigated. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +111006 bogus warnings from linuxthreads =20 -110591 amd64: rdtsc not implemented properly +FIXED-TRUNK: vg:4469, vg:4470 +FIXED-30BRANCH: vg:4497, vg:4498 =20 -Under consideration. (Also afflicts x86) - -FIXED-TRUNK: 1344 (x86), 1346 (amd64). -FIXED-30BRANCH: 1354 (x86), 1355 (amd64). - ---------------------------------------------------------------- +111090 Internal Error running Massif =20 -Nick r4384 (stub implementations of Addrcheck and Helgrind) +FIXED-TRUNK: vg:4492 +FIXED-30BRANCH: vg:4509 =20 -FIXED-TRUNK: done(4384) -FIXED-30BRANCH: done(4397) - ---------------------------------------------------------------- +111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 =20 -110652 AMD64 valgrind crashes on cwtd instruction +FIXED-TRUNK: vex:1341 +FIXED-30BRANCH: vex:1359 =20 -FIXED-TRUNK: done(1333) -FIXED-30BRANCH: done(1335) - ---------------------------------------------------------------- +111102 (comment #4) Fixed 64-bit unclean "silly arg" message =20 -110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction +FIXED-TRUNK: vg:4476 +FIXED-30BRANCH: vg:4502 =20 -FIXED-TRUNK: done(1334) -FIXED-30BRANCH: done(1336) - ---------------------------------------------------------------- +111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized + memory =20 -110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba +FIXED-TRUNK: vg:4549 +FIXED-30BRANCH: vg:4563 =20 -FIXED-TRUNK: done(4386) -FIXED-30BRANCH: done(4395) - ---------------------------------------------------------------- +111513 Illegal opcode for SSE instruction (x86 movups) +NB. Bug reporter did not yet verify that the fix works. =20 -110657 Small test fixes +FIXED-TRUNK: vex:1362 +FIXED-30BRANCH: vex:1367 =20 -(1) Filter out L3 cache warning messages causing problems -(2) Stop tests/mq failing on 2.4 kernels - -I suppose it would be good to apply these. They seem low risk. - -FIXED-TRUNK: 4429 -FIXED-30BRANCH: 4458 - ---------------------------------------------------------------- +111555 VEX/Makefile: CC is set to gcc =20 -110669 valgrind attach to gdb and quitting gdb hangs valgrind +FIXED-TRUNK: vex:1364, vg:4559 +FIXED-30BRANCH: vex:1365, vg:4560 =20 -Not clear if this is really a Valgrind bug. - -FIXED-TRUNK: no -FIXED-30BRANCH: no - ---------------------------------------------------------------- +CrispinF x86 %eflags.ac problem =20 -110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) +FIXED-TRUNK: vex:1319/vg:4334 +FIXED-30BRANCH: vex:1326, and vg:4334 was copied across as part of vg:43= 64 =20 -FIXED-TRUNK: done(1332) -FIXED-30BRANCH: done(1338) - ---------------------------------------------------------------- +n-i-bz XML <unique> printing wrong =20 -Nick (Cachegrind should not assert when it encounters a client -request.) +FIXED-TRUNK: vg:4355,vg:4357,vg:4358 +FIXED-30BRANCH: vg:4585 =20 -FIXED-TRUNK: done(4391) -FIXED-30BRANCH: done(4393) - ---------------------------------------------------------------- +n-i-bz Dirk r4359 (amd64 syscalls from trunk) =20 -110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) +FIXED-TRUNK: =20 +FIXED-30BRANCH: vg:4359 =20 -FIXED-TRUNK: 1349 -FIXED-30BRANCH: 1356 - ---------------------------------------------------------------- +n-i-bz Dirk r4360 (upd email addrs from trunk) =20 -110770 VEX: Generated files not always updated when making valgrind +FIXED-TRUNK: =20 +FIXED-30BRANCH: vg:4360 =20 -FIXED-TRUNK: partial(4473) -FIXED-30BRANCH: TODO - ---------------------------------------------------------------- +n-i-bz Nick r4384 (stub implementations of Addrcheck and Helgrind) =20 -110830 configuring with --host fails to build 32 bit on 64 bit target +FIXED-TRUNK: vg:4384 +FIXED-30BRANCH: vg:4397 =20 -FIXED-TRUNK: 4442 -FIXED-30BRANCH: 4459 - ---------------------------------------------------------------- +n-i-bz Nick (Cachegrind should not assert when it encounters a client +request.) =20 -110875 Assertion when execve fails +FIXED-TRUNK: vg:4391 +FIXED-30BRANCH: vg:4393 =20 -FIXED-TRUNK: 4435 -FIXED-30BRANCH: 4457 - ---------------------------------------------------------------- - Updates to Memcheck manual =20 -FIXED-TRUNK: 4419, 4427, 4434 -FIXED-30BRANCH: 4455 +FIXED-TRUNK: vg:4419, vg:4427, vg:4434 +FIXED-30BRANCH: vg:4455 =20 ---------------------------------------------------------------- - Fixed broken malloc_usable_size() =20 -FIXED-TRUNK: 4439 -FIXED-30BRANCH: 4453 +FIXED-TRUNK: vg:4439 +FIXED-30BRANCH: vg:4453 =20 ---------------------------------------------------------------- +Make suppressions work for "???" lines in stacktraces. =20 -110898 opteron instructions missing: btq sbbq btsq btrq bsfq +FIXED-TRUNK: vg:4447 +FIXED-30BRANCH: vg:4451 =20 -FIXED-TRUNK: 1352 -FIXED-30BRANCH: 1357 - ---------------------------------------------------------------- +n-i-bz vex x86->IR: unhandled instruction bytes: 0x14 0x0 =20 -110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) +FIXED-TRUNK: vex:1350 (basic fix), vex:1351 (x86 adc/sbb flags thunk = fix), + vex:1353 (amd64 adc/sbb flags thunk fi= x) +FIXED-30BRANCH: vex:1360 =20 -FIXED-TRUNK: 1343 -FIXED-30BRANCH: 1358 - ---------------------------------------------------------------- +n-i-bz minor umount/fcntl wrapper fixes =20 -Make suppressions work for "???" lines in stacktraces. +FIXED-TRUNK: vg:4487 +FIXED-30BRANCH: vg:4562 =20 -FIXED-TRUNK: 4447 -FIXED-30BRANCH: 4451 - ---------------------------------------------------------------- +n-i-bz Fix XML bugs in FAQ =20 =20 -111006 bogus warnings from linuxthreads +FIXED-TRUNK: vg:4528 +FIXED-30BRANCH: vg:4564 =20 -FIXED-TRUNK: 4469, 4470 -FIXED-30BRANCH: 4497, 4498 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs targeted for 3.1.0 and 3.0.2 = =3D=3D=3D +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +110209 --show-emwarns misses some =20 -111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 +Tom says: The math/test-fenv.c file in the glibc source is the code in +question and I can reproduce it with that code. =20 -FIXED-TRUNK: 1341 -FIXED-30BRANCH: 1359 +FIXED-TRUNK: TODO? +FIXED-30BRANCH: TODO? =20 ---------------------------------------------------------------- +110770 VEX: Generated files not always updated when making valgrind =20 -111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized - memory +FIXED-TRUNK: TODO... partial(vg:4473) +FIXED-30BRANCH: TODO =20 -FIXED-TRUNK: 4549 -FIXED-30BRANCH: 4563 =20 ----------------------------------------------------------------- =20 -111102 (comment #4) Fixed 64-bit unclean "silly arg" message - -FIXED-TRUNK: 4476 -FIXED-30BRANCH: 4502 - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +=3D=3D=3D Bugs of note not targeted for any particular release +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------- +n-i-bz x86 INT/INT3 =20 -not-in-bugzilla vex x86->IR: unhandled instruction bytes: 0x14 0x0 +Not started. Seems low priority. =20 -FIXED-TRUNK: 1350 (basic fix), 1351 (x86 adc/sbb flags thunk fix), - 1353 (amd64 adc/sbb flags thunk fix) -FIXED-30BRANCH: 1360 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +87263 x86 segment stuff =20 -not-in-bugzilla minor umount/fcntl wrapper fixes +Not started. Seems low priority. =20 -FIXED-TRUNK: 4487 -FIXED-30BRANCH: 4562 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +88116 x86 enter variants assert =20 -111090 Internal Error running Massif +Not started. Seems low priority. =20 -FIXED-TRUNK: 4492 -FIXED-30BRANCH: 4509 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +96542 x86 16-bit pop insns =20 -101204 noisy warning +Not started. Seems low priority. =20 -FIXED-TRUNK: 4511 -FIXED-30BRANCH: 4561 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110201 x86 FXTRACT =20 -111513 Illegal opcode for SSE instruction (x86 movups) -NB. Bug reporter did not yet verify that the fix works. +Could fix if important. =20 -FIXED-TRUNK: 1362 -FIXED-30BRANCH: 1367 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110207 mpn accuracy + +110240 x86 FP differences =20 -111555 VEX/Makefile: CC is set to gcc +Can't be easily fixed (x86 rounding/precision problem) ++ not convinced it's a big problem =20 -FIXED-TRUNK: 1364, 4559 -FIXED-30BRANCH: 1365, 4560 +FIXED-TRUNK: TODO? =20 ---------------------------------------------------------------- +110669 valgrind attach to gdb and quitting gdb hangs valgrind =20 -not-in-bugzilla Fix XML bugs in FAQ =20 +Not clear if this is really a Valgrind bug. =20 -FIXED-TRUNK: 4528 -FIXED-30BRANCH: 4564 +FIXED-TRUNK: TODO? =20 |
|
From: Nicholas N. <nj...@cs...> - 2005-08-29 20:29:57
|
On Mon, 29 Aug 2005, Jeroen N. Witmond wrote: > I have put together a set of xslt files (650 lines) that can be used with > xsltproc to transform file docs/xml/FAQ.xml into the plain text version of > that file. You will find these stylesheets in the attached tarball (11KB). > There you'll also find file README.txt with more information. Ah, wonderful! You've done a very nice job of preserving the layout in the FAQ.txt file. Thanks for the detailed documentation, too. Julian has been preparing 3.0.1 today. This probably won't get into that release, but it will definitely be in the next release. Thank you very much for your effort with this, it is much appreciated. Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-29 18:34:32
|
Greetings, I have put together a set of xslt files (650 lines) that can be used with xsltproc to transform file docs/xml/FAQ.xml into the plain text version of that file. You will find these stylesheets in the attached tarball (11KB). There you'll also find file README.txt with more information. Jeroen. |
|
From: Stefan H. <st...@ho...> - 2005-08-29 14:10:24
|
sv...@va... wrote:
> Modified: branches/VALGRIND_3_0_BRANCH/NEWS
> ===================================================================
> --- branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:44:43 UTC (rev 4569)
> +++ branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:45:48 UTC (rev 4570)
> @@ -1,4 +1,62 @@
>
> +Release 3.0.1 (29 August 2005)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new
> +functionality. Some of the fixed bugs are critical, so if you
> +use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed
^^^
I think it should be "an upgrade".
Best regards,
Stefan
|
|
From: <sv...@va...> - 2005-08-29 13:45:50
|
Author: sewardj Date: 2005-08-29 14:45:48 +0100 (Mon, 29 Aug 2005) New Revision: 4570 Log: track changes from trunk/NEWS Modified: branches/VALGRIND_3_0_BRANCH/NEWS Modified: branches/VALGRIND_3_0_BRANCH/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:44:43 UTC (rev 4569) +++ branches/VALGRIND_3_0_BRANCH/NEWS 2005-08-29 13:45:48 UTC (rev 4570) @@ -1,4 +1,62 @@ =20 +Release 3.0.1 (29 August 2005) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new +functionality. Some of the fixed bugs are critical, so if you +use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed +bugs are: + +(note: "n-i-bz" means "not in bugzilla" -- this bug does not have + a bugzilla entry). + +109313 (=3D=3D 110505) x86 cmpxchg8b +n-i-bz x86: track but ignore changes to %eflags.AC (alignment check) +110102 dis_op2_E_G(amd64) +110202 x86 sys_waitpid(#286) +110203 clock_getres(,0) +110208 execve fail wrong retval +110274 SSE1 now mandatory for x86 +110388 amd64 0xDD 0xD1 +110464 amd64 0xDC 0x1D FCOMP +110478 amd64 0xF 0xD PREFETCH +n-i-bz XML <unique> printing wrong +n-i-bz Dirk r4359 (amd64 syscalls from trunk) +110591 amd64 and x86: rdtsc not implemented properly +n-i-bz Nick r4384 (stub implementations of Addrcheck and Helgrind) +110652 AMD64 valgrind crashes on cwtd instruction +110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction +110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba +110657 Small test fixes +110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) +n-i-bz Nick (Cachegrind should not assert when it encounters a client + request.) +110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) +110830 configuring with --host fails to build 32 bit on 64 bit target +110875 Assertion when execve fails +n-i-bz Updates to Memcheck manual +n-i-bz Fixed broken malloc_usable_size() +110898 opteron instructions missing: btq btsq btrq bsfq +110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) +n-i-bz Make suppressions work for "???" lines in stacktraces. +111006 bogus warnings from linuxthreads +111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 +111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized + memory +111102 (comment #4) Fixed 64-bit unclean "silly arg" message +n-i-bz vex x86->IR: unhandled instruction bytes: 0x14 0x0 +n-i-bz minor umount/fcntl wrapper fixes +111090 Internal Error running Massif +101204 noisy warning +111513 Illegal opcode for SSE instruction (x86 movups) +111555 VEX/Makefile: CC is set to gcc +n-i-bz Fix XML bugs in FAQ =20 + +(3.0.1RC1: 29 August 05,=20 + vex/branches/VEX_3_0_BRANCH r1367,=20 + valgrind/branches/VALGRIND_3_0_BRANCH r4570). + + + Release 3.0.0 (3 August 2005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user |
|
From: <sv...@va...> - 2005-08-29 13:44:49
|
Author: sewardj Date: 2005-08-29 14:44:43 +0100 (Mon, 29 Aug 2005) New Revision: 4569 Log: mark 3.0.1RC1 Modified: trunk/NEWS Modified: trunk/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/NEWS 2005-08-29 13:44:08 UTC (rev 4568) +++ trunk/NEWS 2005-08-29 13:44:43 UTC (rev 4569) @@ -51,7 +51,12 @@ 111555 VEX/Makefile: CC is set to gcc n-i-bz Fix XML bugs in FAQ =20 =20 +(3.0.1RC1: 29 August 05,=20 + vex/branches/VEX_3_0_BRANCH r1367,=20 + valgrind/branches/VALGRIND_3_0_BRANCH r4570). =20 + + Release 3.0.0 (3 August 2005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user |
|
From: <sv...@va...> - 2005-08-29 13:44:10
|
Author: sewardj Date: 2005-08-29 14:44:08 +0100 (Mon, 29 Aug 2005) New Revision: 4568 Log: --> 3.0.1RC1 testing point Modified: branches/VALGRIND_3_0_BRANCH/configure.in Modified: branches/VALGRIND_3_0_BRANCH/configure.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/VALGRIND_3_0_BRANCH/configure.in 2005-08-29 13:39:34 UTC (re= v 4567) +++ branches/VALGRIND_3_0_BRANCH/configure.in 2005-08-29 13:44:08 UTC (re= v 4568) @@ -1,5 +1,5 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.0.1.SVN, val...@li...) +AC_INIT(Valgrind, 3.0.1RC1, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE |
|
From: <sv...@va...> - 2005-08-29 13:39:37
|
Author: sewardj Date: 2005-08-29 14:39:34 +0100 (Mon, 29 Aug 2005) New Revision: 4567 Log: Doc versions -> 3.0.1 Modified: branches/VALGRIND_3_0_BRANCH/docs/xml/vg-entities.xml Modified: branches/VALGRIND_3_0_BRANCH/docs/xml/vg-entities.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/VALGRIND_3_0_BRANCH/docs/xml/vg-entities.xml 2005-08-29 13:2= 4:51 UTC (rev 4566) +++ branches/VALGRIND_3_0_BRANCH/docs/xml/vg-entities.xml 2005-08-29 13:3= 9:34 UTC (rev 4567) @@ -7,6 +7,6 @@ =20 <!-- valgrind release + version stuff --> <!ENTITY rel-type "Release"> -<!ENTITY rel-version "3.0.0"> -<!ENTITY rel-date "August 3 2005"> +<!ENTITY rel-version "3.0.1"> +<!ENTITY rel-date "August 29 2005"> =20 |
|
From: <sv...@va...> - 2005-08-29 13:24:52
|
Author: sewardj Date: 2005-08-29 14:24:51 +0100 (Mon, 29 Aug 2005) New Revision: 4566 Log: Update for 3.0.1. Modified: trunk/NEWS Modified: trunk/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/NEWS 2005-08-29 13:22:33 UTC (rev 4565) +++ trunk/NEWS 2005-08-29 13:24:51 UTC (rev 4566) @@ -1,4 +1,57 @@ =20 +Release 3.0.1 (29 August 2005) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +3.0.1 fixes a bunch of bugs reported in 3.0.0. There is no new +functionality. Some of the fixed bugs are critical, so if you +use/distribute 3.0.0, and upgrade to 3.0.1 is recommended. The fixed +bugs are: + +(note: "n-i-bz" means "not in bugzilla" -- this bug does not have + a bugzilla entry). + +109313 (=3D=3D 110505) x86 cmpxchg8b +n-i-bz x86: track but ignore changes to %eflags.AC (alignment check) +110102 dis_op2_E_G(amd64) +110202 x86 sys_waitpid(#286) +110203 clock_getres(,0) +110208 execve fail wrong retval +110274 SSE1 now mandatory for x86 +110388 amd64 0xDD 0xD1 +110464 amd64 0xDC 0x1D FCOMP +110478 amd64 0xF 0xD PREFETCH +n-i-bz XML <unique> printing wrong +n-i-bz Dirk r4359 (amd64 syscalls from trunk) +110591 amd64 and x86: rdtsc not implemented properly +n-i-bz Nick r4384 (stub implementations of Addrcheck and Helgrind) +110652 AMD64 valgrind crashes on cwtd instruction +110653 AMD64 valgrind crashes on sarb $0x4,foo(%rip) instruction +110656 PATH=3D/usr/bin::/bin valgrind foobar stats ./fooba +110657 Small test fixes +110671 vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 (rep ret) +n-i-bz Nick (Cachegrind should not assert when it encounters a client + request.) +110685 amd64->IR: unhandled instruction bytes: 0xE1 0x56 (loope Jb) +110830 configuring with --host fails to build 32 bit on 64 bit target +110875 Assertion when execve fails +n-i-bz Updates to Memcheck manual +n-i-bz Fixed broken malloc_usable_size() +110898 opteron instructions missing: btq btsq btrq bsfq +110954 x86->IR: unhandled instruction bytes: 0xE2 0xF6 (loop Jb) +n-i-bz Make suppressions work for "???" lines in stacktraces. +111006 bogus warnings from linuxthreads +111092 x86: dis_Grp2(Reg): unhandled case(x86)=20 +111231 sctp_getladdrs() and sctp_getpaddrs() returns uninitialized + memory +111102 (comment #4) Fixed 64-bit unclean "silly arg" message +n-i-bz vex x86->IR: unhandled instruction bytes: 0x14 0x0 +n-i-bz minor umount/fcntl wrapper fixes +111090 Internal Error running Massif +101204 noisy warning +111513 Illegal opcode for SSE instruction (x86 movups) +111555 VEX/Makefile: CC is set to gcc +n-i-bz Fix XML bugs in FAQ =20 + + Release 3.0.0 (3 August 2005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user |
|
From: Nicholas N. <nj...@cs...> - 2005-08-29 13:22:48
|
On Wed, 24 Aug 2005, Greg Parker wrote: I examined Valgrind's generic syscall wrappers and compared them to Darwin / Mac OS X's syscall list. > # The following groups of syscalls are mostly not generic > # and should be handled en masse: > *16 > *xattr > clock_* > mq_* > msg* > rt_sig* > sched_* > sig* > timer_* I've moved *16, clock_*, mq_* and timer_* so far. > # Unused and not generic - possibly keep in syswrap-generic.c > fcntl64 (flags are different) Should this be in the "Not generic" category below? > msgctl (no vki_msgbuf) > msgrcv (no vki_msgbuf) > msgsnd (no vki_msgbuf) I haven't done these ones yet because they're odd... on AMD64/Linux they're separate syscalls, on x86/Linux they're part of the super "socketcall" syscall. Looking more closely, they should be moved. > sched_getparam (no vki_sched_param) > sched_setparam (no vki_sched_param) > sched_setscheduler (no vki_sched_param) > utime (no vki_utimbuf) I think these, as well as the sched_* ones that don't cause compile failures, are POSIX? Perhaps they should just go in the Linux-specific part for now, and we can create a syswrap-posix.c file later if necessary. > # Not generic - probably move to OS-specific files > fgetxattr (darwin has another parameter) > flistxattr (darwin has another parameter) > fremovexattr (darwin has another parameter) > fsetxattr (darwin has another parameter) > getxattr (darwin has another parameter) > kill (darwin has another parameter) > listxattr (darwin has another parameter) > lseek (darwin's off_t is 64 bits even on 32-bit archs) > mmap (darwin's off_t is 64 bits even on 32-bit archs) > munlockall (darwin has another parameter) > pipe (darwin has different parameters and return value) > quotactl (darwin has different parameters) > removexattr (darwin has another parameter) > setxattr (darwin has another parameter) > sigpending (darwin only has one sigset_t type > sigprocmask (darwin only has one sigset_t type) > waitid (darwin has different parameters) I haven't moved these yet, but I guess I will. |
|
From: <sv...@va...> - 2005-08-29 13:22:34
|
Author: sewardj
Date: 2005-08-29 14:22:33 +0100 (Mon, 29 Aug 2005)
New Revision: 4565
Log:
Update (hopefully this is the final change for 3.0.1)
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-29 13:21:19 UTC (rev 4=
564)
+++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-29 13:22:33 UTC (rev 4=
565)
@@ -400,7 +400,7 @@
memory
=20
FIXED-TRUNK: 4549
-FIXED-30BRANCH: TODO
+FIXED-30BRANCH: 4563
=20
----------------------------------------------------------------
=20
@@ -422,7 +422,7 @@
not-in-bugzilla minor umount/fcntl wrapper fixes
=20
FIXED-TRUNK: 4487
-FIXED-30BRANCH: TODO
+FIXED-30BRANCH: 4562
=20
----------------------------------------------------------------
=20
@@ -436,19 +436,27 @@
101204 noisy warning
=20
FIXED-TRUNK: 4511
-FIXED-30BRANCH: TODO
+FIXED-30BRANCH: 4561
=20
----------------------------------------------------------------
=20
+111513 Illegal opcode for SSE instruction (x86 movups)
+NB. Bug reporter did not yet verify that the fix works.
+
+FIXED-TRUNK: 1362
+FIXED-30BRANCH: 1367
+
+----------------------------------------------------------------
+
111555 VEX/Makefile: CC is set to gcc
=20
-FIXED-TRUNK: TODO
-FIXED-30BRANCH: TODO
+FIXED-TRUNK: 1364, 4559
+FIXED-30BRANCH: 1365, 4560
=20
----------------------------------------------------------------
=20
not-in-bugzilla Fix XML bugs in FAQ =20
=20
FIXED-TRUNK: 4528
-FIXED-30BRANCH: TODO
+FIXED-30BRANCH: 4564
=20
|
|
From: <sv...@va...> - 2005-08-29 13:21:23
|
Author: sewardj
Date: 2005-08-29 14:21:19 +0100 (Mon, 29 Aug 2005)
New Revision: 4564
Log:
Merge r4528 (Fix XML bugs in the FAQ.)
Modified:
branches/VALGRIND_3_0_BRANCH/docs/xml/FAQ.xml
Modified: branches/VALGRIND_3_0_BRANCH/docs/xml/FAQ.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/VALGRIND_3_0_BRANCH/docs/xml/FAQ.xml 2005-08-29 12:55:36 UTC=
(rev 4563)
+++ branches/VALGRIND_3_0_BRANCH/docs/xml/FAQ.xml 2005-08-29 13:21:19 UTC=
(rev 4564)
@@ -102,9 +102,7 @@
<qandaentry id=3D"faq.exit_errors">
<question>
<para>Programs run OK on Valgrind, but at exit produce a bunch
- of errors a bit like this:</para>
- </question>
- <answer><para>
+ of errors a bit like this:
<programlisting>
=3D=3D20755=3D=3D Invalid read of size 4
=3D=3D20755=3D=3D at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
@@ -119,6 +117,8 @@
</programlisting>
=20
and then die with a segmentation fault.</para>
+ </question>
+ <answer>
<para>When the program exits, Valgrind runs the procedure
<literal>__libc_freeres()</literal> in glibc. This is a hook
for memory debuggers, so they can ask glibc to free up any
@@ -138,12 +138,12 @@
<qandaentry id=3D"faq.bugdeath">
<question>
<para>My (buggy) program dies like this:</para>
- </question>
- <answer>
<screen>
% valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >=3D 0' fai=
led.
</screen>
=20
+ </question>
+ <answer>
<para>If Memcheck (the memory checker) shows any invalid reads,
invalid writes and invalid frees in your program, the above may
happen. Reason is that your program may trash Valgrind's
@@ -158,12 +158,12 @@
<question>
<para>My program dies, printing a message like this along the
way:</para>
- </question>
- <answer>
<screen>
% disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5
</screen>
=20
+ </question>
+ <answer>
<para>Older versions did not support some x86 instructions,
particularly SSE/SSE2 instructions. Try a newer Valgrind; we
now support almost all instructions. If it still happens with
@@ -422,8 +422,6 @@
<qandaentry id=3D"faq.overruns">
<question>
<para>Why doesn't Memcheck find the array overruns in this program?</p=
ara>
- </question>
- <answer>
<programlisting>
int static[5];
=20
@@ -437,6 +435,8 @@
return 0;
}
</programlisting>
+ </question>
+ <answer>
<para>Unfortunately, Memcheck doesn't do bounds checking on
static or stack arrays. We'd like to, but it's just not
possible to do in a reasonable way that fits with how Memcheck
|
|
From: <sv...@va...> - 2005-08-29 13:06:35
|
Author: sewardj
Date: 2005-08-29 14:06:32 +0100 (Mon, 29 Aug 2005)
New Revision: 1367
Log:
Merge r1362 (Implement MOVUPS -- move from G (xmm) to E (mem or xmm))
Modified:
branches/VEX_3_0_BRANCH/priv/guest-x86/toIR.c
Modified: branches/VEX_3_0_BRANCH/priv/guest-x86/toIR.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/VEX_3_0_BRANCH/priv/guest-x86/toIR.c 2005-08-29 13:03:15 UTC=
(rev 1366)
+++ branches/VEX_3_0_BRANCH/priv/guest-x86/toIR.c 2005-08-29 13:06:32 UTC=
(rev 1367)
@@ -7490,15 +7490,17 @@
}
=20
/* 0F 29 =3D MOVAPS -- move from G (xmm) to E (mem or xmm). */
- if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x29) {
+ /* 0F 11 =3D MOVUPS -- move from G (xmm) to E (mem or xmm). */
+ if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F=20
+ && (insn[1] =3D=3D 0x29 || insn[1] =3D=3D 0x11)) {
modrm =3D getIByte(delta+2);
if (epartIsReg(modrm)) {
/* fall through; awaiting test case */
} else {
addr =3D disAMode ( &alen, sorb, delta+2, dis_buf );
storeLE( mkexpr(addr), getXMMReg(gregOfRM(modrm)) );
- DIP("movaps %s,%s\n", nameXMMReg(gregOfRM(modrm)),
- dis_buf );
+ DIP("mov[ua]ps %s,%s\n", nameXMMReg(gregOfRM(modrm)),
+ dis_buf );
delta +=3D 2+alen;
goto decode_success;
}
|
|
From: <sv...@va...> - 2005-08-29 13:03:17
|
Author: sewardj
Date: 2005-08-29 14:03:15 +0100 (Mon, 29 Aug 2005)
New Revision: 1366
Log:
Merge r1361 (vex_printf/sprintf hackery.)
Modified:
branches/VEX_3_0_BRANCH/priv/main/vex_util.c
branches/VEX_3_0_BRANCH/priv/main/vex_util.h
Modified: branches/VEX_3_0_BRANCH/priv/main/vex_util.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/VEX_3_0_BRANCH/priv/main/vex_util.c 2005-08-29 12:35:57 UTC =
(rev 1365)
+++ branches/VEX_3_0_BRANCH/priv/main/vex_util.c 2005-08-29 13:03:15 UTC =
(rev 1366)
@@ -179,26 +179,6 @@
New code for vex_util.c should go above this point. */
#include <stdarg.h>
=20
-/* ---------------------------------------------------------------------
- printf implementation. The key function, vg_vprintf(), emits chars=20
- into a caller-supplied function. Distantly derived from:
-
- vprintf replacement for Checker.
- Copyright 1993, 1994, 1995 Tristan Gingold
- Written September 1993 Tristan Gingold
- Tristan Gingold, 8 rue Parmentier, F-91120 PALAISEAU, FRANCE
-
- (Checker itself was GPL'd.)
- ------------------------------------------------------------------ */
-
-static HChar vex_toupper ( HChar c )
-{
- if (c >=3D 'a' && c <=3D 'z')
- return toHChar(c + ('A' - 'a'));
- else
- return c;
-}
-
static Int vex_strlen ( const HChar* str )
{
Int i =3D 0;
@@ -218,252 +198,211 @@
}
}
=20
-/* Some flags. */
-#define VG_MSG_SIGNED 1 /* The value is signed. */
-#define VG_MSG_ZJUSTIFY 2 /* Must justify with '0'. */
-#define VG_MSG_LJUSTIFY 4 /* Must justify on the left. */
-#define VG_MSG_PAREN 8 /* Parenthesize if present (for %y) */
-#define VG_MSG_COMMA 16 /* Add commas to numbers (for %d, %u) */
=20
-/* Copy a string into the buffer. */
-static UInt
-myvprintf_str ( void(*send)(HChar), Int flags, Int width, HChar* str,=20
- Bool capitalise )
+/* Convert N0 into ascii in BUF, which is assumed to be big enough (at
+ least 67 bytes long). Observe BASE, SYNED and HEXCAPS. */
+static
+void convert_int ( /*OUT*/HChar* buf, Long n0,=20
+ Int base, Bool syned, Bool hexcaps )
{
-# define MAYBE_TOUPPER(ch) toHChar(capitalise ? vex_toupper(ch) : (ch))
- UInt ret =3D 0;
- Int i, extra;
- Int len =3D vex_strlen(str);
+ ULong u0;
+ HChar c;
+ Bool minus =3D False;
+ Int i, j, bufi =3D 0;
+ buf[bufi] =3D 0;
=20
- if (width =3D=3D 0) {
- ret +=3D len;
- for (i =3D 0; i < len; i++)
- send(MAYBE_TOUPPER(str[i]));
- return ret;
+ if (syned) {
+ if (n0 < 0) {
+ minus =3D True;
+ u0 =3D (ULong)(-n0);
+ } else {
+ u0 =3D (ULong)(n0);
+ }
+ } else {
+ u0 =3D (ULong)n0;
}
=20
- if (len > width) {
- ret +=3D width;
- for (i =3D 0; i < width; i++)
- send(MAYBE_TOUPPER(str[i]));
- return ret;
+ while (1) {
+ buf[bufi++] =3D '0' + (HChar)(u0 % base);
+ u0 /=3D base;
+ if (u0 =3D=3D 0) break;
}
+ if (minus)
+ buf[bufi++] =3D '-';
=20
- extra =3D width - len;
- if (flags & VG_MSG_LJUSTIFY) {
- ret +=3D extra;
- for (i =3D 0; i < extra; i++)
- send(' ');
- }
- ret +=3D len;
- for (i =3D 0; i < len; i++)
- send(MAYBE_TOUPPER(str[i]));
- if (!(flags & VG_MSG_LJUSTIFY)) {
- ret +=3D extra;
- for (i =3D 0; i < extra; i++)
- send(' ');
- }
+ buf[bufi] =3D 0;
+ for (i =3D 0; i < bufi; i++)
+ if (buf[i] > '9')=20
+ buf[i] +=3D ((hexcaps ? 'A' : 'a') - '9' - 1);
=20
-# undef MAYBE_TOUPPER
-
- return ret;
+ i =3D 0;
+ j =3D bufi-1;
+ while (i <=3D j) {
+ c =3D buf[i];
+ buf[i] =3D buf[j];
+ buf[j] =3D c;
+ i++;
+ j--;
+ }
}
=20
-/* Write P into the buffer according to these args:
- * If SIGN is true, p is a signed.
- * BASE is the base.
- * If WITH_ZERO is true, '0' must be added.
- * WIDTH is the width of the field.
- */
-static UInt
-myvprintf_int64 ( void(*send)(HChar), Int flags, Int base, Int width, UL=
ong p)
+
+/* A half-arsed and buggy, but good-enough, implementation of
+ printf. */
+static
+UInt vprintf_wrk ( void(*sink)(HChar),
+ HChar* format,
+ va_list ap )
{
- HChar buf[40];
- Int ind =3D 0;
- Int i, nc =3D 0;
- Bool neg =3D False;
- HChar *digits =3D "0123456789ABCDEF";
- UInt ret =3D 0;
+# define PUT(_ch) \
+ do { sink(_ch); nout++; } \
+ while (0)
=20
- if (base < 2 || base > 16)
- return ret;
-=20
- if ((flags & VG_MSG_SIGNED) && (Long)p < 0) {
- p =3D - (Long)p;
- neg =3D True;
- }
+# define PAD(_n) \
+ do { Int _qq =3D (_n); for (; _qq > 0; _qq--) PUT(padchar); } \
+ while (0)
=20
- if (p =3D=3D 0)
- buf[ind++] =3D '0';
- else {
- while (p > 0) {
- if ((flags & VG_MSG_COMMA) && 10 =3D=3D base &&
- 0 =3D=3D (ind-nc) % 3 && 0 !=3D ind)=20
- {
- buf[ind++] =3D ',';
- nc++;
- }
- buf[ind++] =3D digits[p % base];
- p /=3D base;
- }
- }
+# define PUTSTR(_str) \
+ do { HChar* _qq =3D _str; for (; *_qq; _qq++) PUT(*_qq); } \
+ while (0)
=20
- if (neg)
- buf[ind++] =3D '-';
+ HChar* saved_format;
+ Bool longlong, ljustify;
+ HChar padchar;
+ Int fwidth, nout, len1, len2, len3;
+ HChar intbuf[100]; /* big enough for a 64-bit # in base 2 */
=20
- if (width > 0 && !(flags & VG_MSG_LJUSTIFY)) {
- for(; ind < width; ind++) {
- vassert(ind < 39);
- buf[ind] =3D toHChar((flags & VG_MSG_ZJUSTIFY) ? '0': ' ');
- }
- }
+ nout =3D 0;
+ while (1) {
=20
- /* Reverse copy to buffer. */
- ret +=3D ind;
- for (i =3D ind -1; i >=3D 0; i--) {
- send(buf[i]);
- }
- if (width > 0 && (flags & VG_MSG_LJUSTIFY)) {
- for(; ind < width; ind++) {
- ret++;
- send(' '); // Never pad with zeroes on RHS -- changes the valu=
e!
+ if (!format)
+ break;
+ if (*format =3D=3D 0)=20
+ break;
+
+ if (*format !=3D '%') {
+ PUT(*format);=20
+ format++;
+ continue;
}
- }
- return ret;
-}
=20
+ saved_format =3D format;
+ longlong =3D False;
+ ljustify =3D False;
+ padchar =3D ' ';
+ fwidth =3D 0;
+ format++;
=20
-/* A simple vprintf(). */
-static=20
-UInt vprintf_wrk ( void(*send)(HChar), const HChar *format, va_list varg=
s )
-{
- UInt ret =3D 0;
- int i;
- int flags;
- int width;
- Bool is_long;
-
- /* We assume that vargs has already been initialised by the=20
- caller, using va_start, and that the caller will similarly
- clean up with va_end.
- */
-
- for (i =3D 0; format[i] !=3D 0; i++) {
- if (format[i] !=3D '%') {
- send(format[i]);
- ret++;
- continue;
+ if (*format =3D=3D '-') {
+ format++;
+ ljustify =3D True;
}
- i++;
- /* A '%' has been found. Ignore a trailing %. */
- if (format[i] =3D=3D 0)
- break;
- if (format[i] =3D=3D '%') {
- /* `%%' is replaced by `%'. */
- send('%');
- ret++;
- continue;
+ if (*format =3D=3D '0') {
+ format++;
+ padchar =3D '0';
}
- flags =3D 0;
- is_long =3D False;
- width =3D 0; /* length of the field. */
- if (format[i] =3D=3D '(') {
- flags |=3D VG_MSG_PAREN;
- i++;
+ while (*format >=3D '0' && *format <=3D '9') {
+ fwidth =3D fwidth * 10 + (*format - '0');
+ format++;
}
- /* If ',' follows '%', commas will be inserted. */
- if (format[i] =3D=3D ',') {
- flags |=3D VG_MSG_COMMA;
- i++;
+ if (*format =3D=3D 'l') {
+ format++;
+ if (*format =3D=3D 'l') {
+ format++;
+ longlong =3D True;
+ }
}
- /* If '-' follows '%', justify on the left. */
- if (format[i] =3D=3D '-') {
- flags |=3D VG_MSG_LJUSTIFY;
- i++;
- }
- /* If '0' follows '%', pads will be inserted. */
- if (format[i] =3D=3D '0') {
- flags |=3D VG_MSG_ZJUSTIFY;
- i++;
- }
- /* Compute the field length. */
- while (format[i] >=3D '0' && format[i] <=3D '9') {
- width *=3D 10;
- width +=3D format[i++] - '0';
- }
- while (format[i] =3D=3D 'l') {
- i++;
- is_long =3D True;
- }
=20
- switch (format[i]) {
- case 'd': /* %d */
- flags |=3D VG_MSG_SIGNED;
- if (is_long)
- ret +=3D myvprintf_int64(send, flags, 10, width,=20
- (ULong)(va_arg (vargs, Long)));
- else
- ret +=3D myvprintf_int64(send, flags, 10, width,=20
- (ULong)(va_arg (vargs, Int)));
+ switch (*format) {
+ case 's': {
+ HChar* str =3D va_arg(ap, HChar*);
+ if (str =3D=3D NULL)
+ str =3D "(null)";
+ len1 =3D len3 =3D 0;
+ len2 =3D vex_strlen(str);
+ if (fwidth > len2) { len1 =3D ljustify ? fwidth-len2 : 0;
+ len3 =3D ljustify ? 0 : fwidth-len2; }
+ PAD(len1); PUTSTR(str); PAD(len3);
break;
- case 'u': /* %u */
- if (is_long)
- ret +=3D myvprintf_int64(send, flags, 10, width,=20
- (ULong)(va_arg (vargs, ULong)));
- else
- ret +=3D myvprintf_int64(send, flags, 10, width,=20
- (ULong)(va_arg (vargs, UInt)));
+ }
+ case 'c': {
+ HChar c =3D (HChar)va_arg(ap, int);
+ HChar str[2];
+ str[0] =3D c;
+ str[1] =3D 0;
+ len1 =3D len3 =3D 0;
+ len2 =3D vex_strlen(str);
+ if (fwidth > len2) { len1 =3D ljustify ? fwidth-len2 : 0;
+ len3 =3D ljustify ? 0 : fwidth-len2; }
+ PAD(len1); PUTSTR(str); PAD(len3);
break;
- case 'p': /* %p */
- ret +=3D 2;
- send('0');
- send('x');
- ret +=3D myvprintf_int64(send, flags, 16, width,=20
- (ULong)((HWord)va_arg (vargs, void *)=
));
+ }
+ case 'd': {
+ Long l;
+ if (longlong) {
+ l =3D va_arg(ap, Long);
+ } else {
+ l =3D (Long)va_arg(ap, Int);
+ }
+ convert_int(intbuf, l, 10/*base*/, True/*signed*/,
+ False/*irrelevant*/);
+ len1 =3D len3 =3D 0;
+ len2 =3D vex_strlen(intbuf);
+ if (fwidth > len2) { len1 =3D ljustify ? fwidth-len2 : 0;
+ len3 =3D ljustify ? 0 : fwidth-len2; }
+ PAD(len1); PUTSTR(intbuf); PAD(len3);
break;
- case 'x': /* %x */
- if (is_long)
- ret +=3D myvprintf_int64(send, flags, 16, width,=20
- (ULong)(va_arg (vargs, ULong)));
- else
- ret +=3D myvprintf_int64(send, flags, 16, width,=20
- (ULong)(va_arg (vargs, UInt)));
- break;
- case 'c': /* %c */
- ret++;
- send(toHChar(va_arg (vargs, int)));
- break;
- case 's': case 'S': { /* %s */
- char *str =3D va_arg (vargs, char *);
- if (str =3D=3D (char*) 0) str =3D "(null)";
- ret +=3D myvprintf_str(send, flags, width, str,=20
- toBool(format[i]=3D=3D'S'));
- break;
}
-# if 0
- case 'y': { /* %y - print symbol */
- Char buf[100];
- Char *cp =3D buf;
- Addr a =3D va_arg(vargs, Addr);
-
- if (flags & VG_MSG_PAREN)
- *cp++ =3D '(';
- if (VG_(get_fnname_w_offset)(a, cp, sizeof(buf)-4)) {
- if (flags & VG_MSG_PAREN) {
- cp +=3D VG_(strlen)(cp);
- *cp++ =3D ')';
- *cp =3D '\0';
- }
- ret +=3D myvprintf_str(send, flags, width, buf, 0);
+ case 'u':=20
+ case 'x':=20
+ case 'X': {
+ Int base =3D *format =3D=3D 'u' ? 10 : 16;
+ Bool hexcaps =3D True; /* *format =3D=3D 'X'; */
+ ULong l;
+ if (longlong) {
+ l =3D va_arg(ap, ULong);
+ } else {
+ l =3D (ULong)va_arg(ap, UInt);
}
+ convert_int(intbuf, l, base, False/*unsigned*/, hexcaps);
+ len1 =3D len3 =3D 0;
+ len2 =3D vex_strlen(intbuf);
+ if (fwidth > len2) { len1 =3D ljustify ? fwidth-len2 : 0;
+ len3 =3D ljustify ? 0 : fwidth-len2; }
+ PAD(len1); PUTSTR(intbuf); PAD(len3);
break;
}
-# endif
+ case 'p':=20
+ case 'P': {
+ Bool hexcaps =3D *format =3D=3D 'P';
+ ULong l =3D Ptr_to_ULong( va_arg(ap, void*) );
+ convert_int(intbuf, l, 16/*base*/, False/*unsigned*/, hexcap=
s);
+ len1 =3D len3 =3D 0;
+ len2 =3D vex_strlen(intbuf)+2;
+ if (fwidth > len2) { len1 =3D ljustify ? fwidth-len2 : 0;
+ len3 =3D ljustify ? 0 : fwidth-len2; }
+ PAD(len1); PUT('0'); PUT('x'); PUTSTR(intbuf); PAD(len3);
+ break;
+ }
default:
+ /* no idea what it is. Print the format literally and
+ move on. */
+ while (saved_format <=3D format) {
+ PUT(*saved_format);
+ saved_format++;
+ }
break;
}
+
+ format++;
+
}
- return ret;
+
+ return nout;
+
+# undef PUT
+# undef PAD
+# undef PUTSTR
}
=20
=20
@@ -476,16 +415,17 @@
=20
static void add_to_myprintf_buf ( HChar c )
{
- if (c =3D=3D '\n' || n_myprintf_buf >=3D 1000-10 /*paranoia*/ ) {
+ Bool emit =3D c =3D=3D '\n' || n_myprintf_buf >=3D 1000-10 /*paranoia=
*/;
+ myprintf_buf[n_myprintf_buf++] =3D c;
+ myprintf_buf[n_myprintf_buf] =3D 0;
+ if (emit) {
(*vex_log_bytes)( myprintf_buf, vex_strlen(myprintf_buf) );
n_myprintf_buf =3D 0;
- myprintf_buf[n_myprintf_buf] =3D 0; =20
+ myprintf_buf[n_myprintf_buf] =3D 0;
}
- myprintf_buf[n_myprintf_buf++] =3D c;
- myprintf_buf[n_myprintf_buf] =3D 0;
}
=20
-UInt vex_printf ( const char *format, ... )
+UInt vex_printf ( HChar* format, ... )
{
UInt ret;
va_list vargs;
@@ -514,7 +454,7 @@
*vg_sprintf_ptr++ =3D c;
}
=20
-UInt vex_sprintf ( HChar* buf, const HChar *format, ... )
+UInt vex_sprintf ( HChar* buf, HChar *format, ... )
{
Int ret;
va_list vargs;
Modified: branches/VEX_3_0_BRANCH/priv/main/vex_util.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/VEX_3_0_BRANCH/priv/main/vex_util.h 2005-08-29 12:35:57 UTC =
(rev 1365)
+++ branches/VEX_3_0_BRANCH/priv/main/vex_util.h 2005-08-29 13:03:15 UTC =
(rev 1366)
@@ -75,10 +75,10 @@
/* Printing */
=20
__attribute__ ((format (printf, 1, 2)))
-extern UInt vex_printf ( const HChar *format, ... );
+extern UInt vex_printf ( HChar *format, ... );
=20
__attribute__ ((format (printf, 2, 3)))
-extern UInt vex_sprintf ( HChar* buf, const HChar *format, ... );
+extern UInt vex_sprintf ( HChar* buf, HChar *format, ... );
=20
=20
/* String ops */
|
|
From: <sv...@va...> - 2005-08-29 12:55:38
|
Author: sewardj
Date: 2005-08-29 13:55:36 +0100 (Mon, 29 Aug 2005)
New Revision: 4563
Log:
Merge r4549 (Handle the SCTP_GET_LOCAL_ADDRS and SCTP_GET_PEER_ADDRS
getsockopt calls correctly.)
Modified:
branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c
branches/VALGRIND_3_0_BRANCH/include/vki-amd64-linux.h
branches/VALGRIND_3_0_BRANCH/include/vki-linux.h
branches/VALGRIND_3_0_BRANCH/include/vki-ppc32-linux.h
branches/VALGRIND_3_0_BRANCH/include/vki-x86-linux.h
Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generi=
c.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/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
05-08-29 12:51:05 UTC (rev 4562)
+++ branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
05-08-29 12:55:36 UTC (rev 4563)
@@ -1146,10 +1146,17 @@
Addr optval_p =3D arg3;
Addr optlen_p =3D arg4;
/* vg_assert(sizeof(socklen_t) =3D=3D sizeof(UInt)); */
- if (optval_p !=3D (Addr)NULL)=20
+ if (optval_p !=3D (Addr)NULL) {
buf_and_len_pre_check ( tid, optval_p, optlen_p,
"socketcall.getsockopt(optval)",
"socketcall.getsockopt(optlen)" );
+ if (arg1 =3D=3D VKI_SOL_SCTP &&
+ (arg2 =3D=3D VKI_SCTP_GET_PEER_ADDRS || arg2 =3D=3D VKI_SCTP_G=
ET_LOCAL_ADDRS)) {
+ struct vki_sctp_getaddrs *ga =3D (struct vki_sctp_getaddrs*)arg=
3;
+ int address_bytes =3D sizeof(struct vki_sockaddr_in6) * ga->add=
r_num;
+ PRE_MEM_WRITE( "socketcall.getsockopt(optval.addrs)", (Addr)ga-=
>addrs, address_bytes );
+ }
+ }
}
=20
void=20
@@ -1161,9 +1168,28 @@
Addr optval_p =3D arg3;
Addr optlen_p =3D arg4;
vg_assert(!res.isError); /* guaranteed by caller */
- if (optval_p !=3D (Addr)NULL)=20
+ if (optval_p !=3D (Addr)NULL) {
buf_and_len_post_check ( tid, res, optval_p, optlen_p,
"socketcall.getsockopt(optlen_out)" );
+ if (arg1 =3D=3D VKI_SOL_SCTP &&
+ (arg2 =3D=3D VKI_SCTP_GET_PEER_ADDRS || arg2 =3D=3D VKI_SCTP_G=
ET_LOCAL_ADDRS)) {
+ struct vki_sctp_getaddrs *ga =3D (struct vki_sctp_getaddrs*)arg=
3;
+ struct vki_sockaddr *a =3D ga->addrs;
+ int i;
+ for (i =3D 0; i < ga->addr_num; i++) {
+ int sl =3D 0;
+ if (a->sa_family =3D=3D VKI_AF_INET)
+ sl =3D sizeof(struct vki_sockaddr_in);
+ else if (a->sa_family =3D=3D VKI_AF_INET6)
+ sl =3D sizeof(struct vki_sockaddr_in6);
+ else {
+ VG_(message)(Vg_UserMsg, "Warning: getsockopt: unhandled =
address type %d", a->sa_family);
+ }
+ a =3D (struct vki_sockaddr*)((char*)a + sl);
+ }
+ POST_MEM_WRITE( (Addr)ga->addrs, (char*)a - (char*)ga->addrs );
+ }
+ }
}
=20
/* ------ */
Modified: branches/VALGRIND_3_0_BRANCH/include/vki-amd64-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/VALGRIND_3_0_BRANCH/include/vki-amd64-linux.h 2005-08-29 12:=
51:05 UTC (rev 4562)
+++ branches/VALGRIND_3_0_BRANCH/include/vki-amd64-linux.h 2005-08-29 12:=
55:36 UTC (rev 4563)
@@ -44,6 +44,7 @@
typedef __signed__ short __vki_s16;
typedef unsigned short __vki_u16;
=20
+typedef __signed__ int __vki_s32;
typedef unsigned int __vki_u32;
=20
typedef __signed__ long long __vki_s64;
Modified: branches/VALGRIND_3_0_BRANCH/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/VALGRIND_3_0_BRANCH/include/vki-linux.h 2005-08-29 12:51:05 =
UTC (rev 4562)
+++ branches/VALGRIND_3_0_BRANCH/include/vki-linux.h 2005-08-29 12:55:36 =
UTC (rev 4563)
@@ -587,6 +587,8 @@
=20
#define VKI_MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
=20
+#define VKI_SOL_SCTP 132
+
//----------------------------------------------------------------------
// From linux-2.6.8.1/include/linux/in.h
//----------------------------------------------------------------------
@@ -772,6 +774,73 @@
};
=20
//----------------------------------------------------------------------
+// From linux-2.6.13-rc5/include/net/sctp/user.h
+//----------------------------------------------------------------------
+
+typedef __vki_s32 vki_sctp_assoc_t;
+
+enum vki_sctp_optname {
+ VKI_SCTP_RTOINFO,
+#define VKI_SCTP_RTOINFO VKI_SCTP_RTOINFO
+ VKI_SCTP_ASSOCINFO,
+#define VKI_SCTP_ASSOCINFO VKI_SCTP_ASSOCINFO
+ VKI_SCTP_INITMSG,
+#define VKI_SCTP_INITMSG VKI_SCTP_INITMSG
+ VKI_SCTP_NODELAY, /* Get/set nodelay option. */
+#define VKI_SCTP_NODELAY VKI_SCTP_NODELAY
+ VKI_SCTP_AUTOCLOSE,
+#define VKI_SCTP_AUTOCLOSE VKI_SCTP_AUTOCLOSE
+ VKI_SCTP_SET_PEER_PRIMARY_ADDR,=20
+#define VKI_SCTP_SET_PEER_PRIMARY_ADDR VKI_SCTP_SET_PEER_PRIMARY_ADDR
+ VKI_SCTP_PRIMARY_ADDR,
+#define VKI_SCTP_PRIMARY_ADDR VKI_SCTP_PRIMARY_ADDR
+ VKI_SCTP_ADAPTION_LAYER, =20
+#define VKI_SCTP_ADAPTION_LAYER VKI_SCTP_ADAPTION_LAYER
+ VKI_SCTP_DISABLE_FRAGMENTS,
+#define VKI_SCTP_DISABLE_FRAGMENTS VKI_SCTP_DISABLE_FRAGMENTS
+ VKI_SCTP_PEER_ADDR_PARAMS,
+#define VKI_SCTP_PEER_ADDR_PARAMS VKI_SCTP_PEER_ADDR_PARAMS
+ VKI_SCTP_DEFAULT_SEND_PARAM,
+#define VKI_SCTP_DEFAULT_SEND_PARAM VKI_SCTP_DEFAULT_SEND_PARAM
+ VKI_SCTP_EVENTS,
+#define VKI_SCTP_EVENTS VKI_SCTP_EVENTS
+ VKI_SCTP_I_WANT_MAPPED_V4_ADDR, /* Turn on/off mapped v4 addresses */
+#define VKI_SCTP_I_WANT_MAPPED_V4_ADDR VKI_SCTP_I_WANT_MAPPED_V4_ADDR
+ VKI_SCTP_MAXSEG, /* Get/set maximum fragment. */
+#define VKI_SCTP_MAXSEG VKI_SCTP_MAXSEG
+ VKI_SCTP_STATUS,
+#define VKI_SCTP_STATUS VKI_SCTP_STATUS
+ VKI_SCTP_GET_PEER_ADDR_INFO,
+#define VKI_SCTP_GET_PEER_ADDR_INFO VKI_SCTP_GET_PEER_ADDR_INFO
+
+ /* Internal Socket Options. Some of the sctp library functions are=20
+ * implemented using these socket options.
+ */
+ VKI_SCTP_SOCKOPT_BINDX_ADD =3D 100,/* BINDX requests for adding address=
es. */
+#define VKI_SCTP_SOCKOPT_BINDX_ADD VKI_SCTP_SOCKOPT_BINDX_ADD
+ VKI_SCTP_SOCKOPT_BINDX_REM, /* BINDX requests for removing addresses. *=
/
+#define VKI_SCTP_SOCKOPT_BINDX_REM VKI_SCTP_SOCKOPT_BINDX_REM
+ VKI_SCTP_SOCKOPT_PEELOFF, /* peel off association. */
+#define VKI_SCTP_SOCKOPT_PEELOFF VKI_SCTP_SOCKOPT_PEELOFF
+ VKI_SCTP_GET_PEER_ADDRS_NUM, /* Get number of peer addresss. */
+#define VKI_SCTP_GET_PEER_ADDRS_NUM VKI_SCTP_GET_PEER_ADDRS_NUM
+ VKI_SCTP_GET_PEER_ADDRS, /* Get all peer addresss. */
+#define VKI_SCTP_GET_PEER_ADDRS VKI_SCTP_GET_PEER_ADDRS
+ VKI_SCTP_GET_LOCAL_ADDRS_NUM, /* Get number of local addresss. */
+#define VKI_SCTP_GET_LOCAL_ADDRS_NUM VKI_SCTP_GET_LOCAL_ADDRS_NUM
+ VKI_SCTP_GET_LOCAL_ADDRS, /* Get all local addresss. */
+#define VKI_SCTP_GET_LOCAL_ADDRS VKI_SCTP_GET_LOCAL_ADDRS
+ VKI_SCTP_SOCKOPT_CONNECTX, /* CONNECTX requests. */
+#define VKI_SCTP_SOCKOPT_CONNECTX VKI_SCTP_SOCKOPT_CONNECTX
+};
+
+struct vki_sctp_getaddrs {
+ vki_sctp_assoc_t assoc_id;
+ int addr_num;
+ struct vki_sockaddr *addrs;
+};
+
+//----------------------------------------------------------------------
// From linux-2.6.8.1/include/linux/resource.h
//----------------------------------------------------------------------
=20
Modified: branches/VALGRIND_3_0_BRANCH/include/vki-ppc32-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/VALGRIND_3_0_BRANCH/include/vki-ppc32-linux.h 2005-08-29 12:=
51:05 UTC (rev 4562)
+++ branches/VALGRIND_3_0_BRANCH/include/vki-ppc32-linux.h 2005-08-29 12:=
55:36 UTC (rev 4563)
@@ -44,6 +44,7 @@
typedef __signed__ short __vki_s16;
typedef unsigned short __vki_u16;
=20
+typedef __signed__ int __vki_s32;
typedef unsigned int __vki_u32;
=20
typedef __signed__ long long __vki_s64;
Modified: branches/VALGRIND_3_0_BRANCH/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
--- branches/VALGRIND_3_0_BRANCH/include/vki-x86-linux.h 2005-08-29 12:51=
:05 UTC (rev 4562)
+++ branches/VALGRIND_3_0_BRANCH/include/vki-x86-linux.h 2005-08-29 12:55=
:36 UTC (rev 4563)
@@ -43,6 +43,7 @@
typedef __signed__ short __vki_s16;
typedef unsigned short __vki_u16;
=20
+typedef __signed__ int __vki_s32;
typedef unsigned int __vki_u32;
=20
typedef __signed__ long long __vki_s64;
|
|
From: <sv...@va...> - 2005-08-29 12:51:13
|
Author: sewardj
Date: 2005-08-29 13:51:05 +0100 (Mon, 29 Aug 2005)
New Revision: 4562
Log:
Merge r4487 (Minor fixes for problems pointed out by Greg Parker)
Modified:
branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c
branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-linux.c
Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generi=
c.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/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
05-08-29 12:46:36 UTC (rev 4561)
+++ branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
05-08-29 12:51:05 UTC (rev 4562)
@@ -2600,9 +2600,7 @@
case VKI_F_GETFD:
case VKI_F_GETFL:
case VKI_F_GETOWN:
- case VKI_F_SETOWN:
case VKI_F_GETSIG:
- case VKI_F_SETSIG:
case VKI_F_GETLEASE:
PRINT("sys_fcntl ( %d, %d )", ARG1,ARG2);
PRE_REG_READ2(long, "fcntl", unsigned int, fd, unsigned int, cmd);
@@ -2614,6 +2612,8 @@
case VKI_F_SETFL:
case VKI_F_SETLEASE:
case VKI_F_NOTIFY:
+ case VKI_F_SETOWN:
+ case VKI_F_SETSIG:
PRINT("sys_fcntl[ARG3=3D=3D'arg'] ( %d, %d, %d )", ARG1,ARG2,ARG3)=
;
PRE_REG_READ3(long, "fcntl",
unsigned int, fd, unsigned int, cmd, unsigned long, =
arg);
Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-linux.=
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/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-linux.c 2005=
-08-29 12:46:36 UTC (rev 4561)
+++ branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/syswrap-linux.c 2005=
-08-29 12:51:05 UTC (rev 4562)
@@ -168,7 +168,7 @@
=20
PRE(sys_umount)
{
- PRINT("sys_umount( %p )", ARG1);
+ PRINT("sys_umount( %p, %d )", ARG1, ARG2);
PRE_REG_READ2(long, "umount2", char *, path, int, flags);
PRE_MEM_RASCIIZ( "umount2(path)", ARG1);
}
|
|
From: <sv...@va...> - 2005-08-29 12:46:44
|
Author: sewardj
Date: 2005-08-29 13:46:36 +0100 (Mon, 29 Aug 2005)
New Revision: 4561
Log:
Merge r4511 (Only show the "line number too large" warning once.)
Modified:
branches/VALGRIND_3_0_BRANCH/coregrind/m_debuginfo/symtab.c
Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_debuginfo/symtab.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/VALGRIND_3_0_BRANCH/coregrind/m_debuginfo/symtab.c 2005-08-2=
9 12:38:15 UTC (rev 4560)
+++ branches/VALGRIND_3_0_BRANCH/coregrind/m_debuginfo/symtab.c 2005-08-2=
9 12:46:36 UTC (rev 4561)
@@ -273,23 +273,29 @@
/* vg_assert(this < si->start + si->size && next-1 >=3D si->start); *=
/
if (this >=3D si->start + si->size || next-1 < si->start) {
if (0)
- VG_(message)(Vg_DebugMsg,=20
- "warning: ignoring line info entry falling "
- "outside current SegInfo: %p %p %p %p",
- si->start, si->start + si->size,=20
- this, next-1);
+ VG_(message)(Vg_DebugMsg,=20
+ "warning: ignoring line info entry falling "
+ "outside current SegInfo: %p %p %p %p",
+ si->start, si->start + si->size,=20
+ this, next-1);
return;
}
=20
vg_assert(lineno >=3D 0);
if (lineno > MAX_LINENO) {
- VG_(message)(Vg_UserMsg,=20
- "warning: ignoring line info entry with "
- "huge line number (%d)", lineno);
- VG_(message)(Vg_UserMsg,=20
- " Can't handle line numbers "
- "greater than %d, sorry", MAX_LINENO);
- return;
+ static Bool complained =3D False;
+ if (!complained) {
+ complained =3D True;
+ VG_(message)(Vg_UserMsg,=20
+ "warning: ignoring line info entry with "
+ "huge line number (%d)", lineno);
+ VG_(message)(Vg_UserMsg,=20
+ " Can't handle line numbers "
+ "greater than %d, sorry", MAX_LINENO);
+ VG_(message)(Vg_UserMsg,=20
+ "(Nb: this message is only shown once)");
+ }
+ return;
}
=20
loc.addr =3D this;
|
|
From: <sv...@va...> - 2005-08-29 12:38:21
|
Author: sewardj Date: 2005-08-29 13:38:15 +0100 (Mon, 29 Aug 2005) New Revision: 4560 Log: Merge r4559 (Pass $(CC) to the vex Makefile.) Modified: branches/VALGRIND_3_0_BRANCH/coregrind/Makefile.am branches/VALGRIND_3_0_BRANCH/coregrind/m_dispatch/Makefile.am branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/Makefile.am Modified: branches/VALGRIND_3_0_BRANCH/coregrind/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/VALGRIND_3_0_BRANCH/coregrind/Makefile.am 2005-08-29 12:11:0= 6 UTC (rev 4559) +++ branches/VALGRIND_3_0_BRANCH/coregrind/Makefile.am 2005-08-29 12:38:1= 5 UTC (rev 4560) @@ -198,13 +198,13 @@ || rm -f $@ =20 @VEX_DIR@/libvex.a: @VEX_DIR@/priv/main/vex_svnversion.h - $(MAKE) -C @VEX_DIR@ libvex.a EXTRA_CFLAGS=3D"@ARCH_CORE_AM_CFLAGS@ @PI= E_AM_CFLAGS@" + $(MAKE) -C @VEX_DIR@ CC=3D$(CC) libvex.a EXTRA_CFLAGS=3D"@ARCH_CORE_AM_= CFLAGS@ @PIE_AM_CFLAGS@" =20 @VEX_DIR@/priv/main/vex_svnversion.h: $(wildcard @VEX_DIR@/.svn/entries) - $(MAKE) -C @VEX_DIR@ version + $(MAKE) -C @VEX_DIR@ CC=3D$(CC) version =20 clean-local: - $(MAKE) -C @VEX_DIR@ clean + $(MAKE) -C @VEX_DIR@ CC=3D$(CC) clean =20 MANUAL_DEPS =3D $(noinst_HEADERS) $(include_HEADERS) =20 Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_dispatch/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/VALGRIND_3_0_BRANCH/coregrind/m_dispatch/Makefile.am 2005-08= -29 12:11:06 UTC (rev 4559) +++ branches/VALGRIND_3_0_BRANCH/coregrind/m_dispatch/Makefile.am 2005-08= -29 12:38:15 UTC (rev 4560) @@ -13,4 +13,4 @@ dispatch-@VG_ARCH@.S: libvex_guest_offsets.h =20 libvex_guest_offsets.h: - $(MAKE) -C @VEX_DIR@ pub/libvex_guest_offsets.h + $(MAKE) -C @VEX_DIR@ CC=3D$(CC) pub/libvex_guest_offsets.h Modified: branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/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/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/Makefile.am 2005-08-= 29 12:11:06 UTC (rev 4559) +++ branches/VALGRIND_3_0_BRANCH/coregrind/m_syswrap/Makefile.am 2005-08-= 29 12:38:15 UTC (rev 4560) @@ -26,4 +26,4 @@ syswrap-main.c: libvex_guest_offsets.h =20 libvex_guest_offsets.h: - $(MAKE) -C @VEX_DIR@ pub/libvex_guest_offsets.h + $(MAKE) -C @VEX_DIR@ CC=3D$(CC) pub/libvex_guest_offsets.h |