|
From: Julian S. <js...@ac...> - 2005-03-21 18:31:10
|
CVS commit by jseward:
Build fixes for the regtest suite on gcc-2.96.
M +4 -3 memcheck/tests/scalar.c 1.54
M +4 -4 memcheck/tests/str_tester.c 1.2
M +1 -1 none/tests/thread-exits.c 1.4
--- valgrind/memcheck/tests/scalar.c #1.53:1.54
@@ -15,4 +15,8 @@
// always issue an error message immediately before these seg faults occur).
+#include <asm/ipc.h>
+#include <sched.h>
+#include <signal.h>
+
int main(void)
{
@@ -513,5 +517,4 @@ int main(void)
// XXX: Also, should be 6 scalar errors, except glibc's syscall() doesn't
// use the 6th one!
- #include <asm/ipc.h>
GO(__NR_ipc, "5s 0m");
SY(__NR_ipc, x0+4, x0, x0, x0, x0, x0); FAIL;
@@ -526,6 +529,4 @@ int main(void)
// __NR_clone 120
- #include <sched.h>
- #include <signal.h>
#ifndef CLONE_PARENT_SETTID
#define CLONE_PARENT_SETTID 0x00100000
--- valgrind/memcheck/tests/str_tester.c #1.1:1.2
@@ -176,8 +176,8 @@ test_strcpy (void)
/* Simple test using implicitly coerced `void *' arguments. */
- const void *src = "frobozz";
+ { const void *src = "frobozz";
void *dst = one;
check (strcpy (dst, src) == dst, 1);
- equal (dst, "frobozz", 2);
+ equal (dst, "frobozz", 2); }
}
--- valgrind/none/tests/thread-exits.c #1.3:1.4
@@ -93,4 +93,5 @@ int main()
sigset_t mask;
int status;
+ struct sigaction sa;
sigemptyset(&mask);
@@ -98,5 +99,4 @@ int main()
sigprocmask(SIG_BLOCK, &mask, NULL);
- struct sigaction sa;
sa.sa_handler = handler;
sa.sa_flags = 0;
|
|
From: Julian S. <js...@ac...> - 2005-03-24 02:29:55
|
CVS commit by jseward: --> 2.4.0 M +1 -1 configure.in 1.155 --- valgrind/configure.in #1.154:1.155 @@ -1,4 +1,4 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 2.4.0.rc4, val...@li...) +AC_INIT(Valgrind, 2.4.0, val...@li...) AC_CONFIG_SRCDIR(coregrind/vg_main.c) AM_CONFIG_HEADER(config.h) |
|
From: Julian S. <js...@ac...> - 2005-03-24 13:50:26
|
CVS commit by jseward: Add PaulM to this list. M +23 -15 ACKNOWLEDGEMENTS 1.3 --- valgrind/ACKNOWLEDGEMENTS #1.2:1.3 @@ -1,14 +1,3 @@ -Julian Seward, ju...@va... - -Julian was the original designer and author of Valgrind, created the -dynamic translation framework, wrote Memcheck and Addrcheck, and did -lots of other things. - -Nicholas Nethercote, nj...@va... - -Nick did the core/tool generalisation, wrote Cachegrind and Massif, -and tons of other stuff. - Jeremy Fitzhardinge, je...@va... @@ -21,9 +10,15 @@ more recent Linux/glibc versions. -Robert Walsh, rj...@va... +Nicholas Nethercote, nj...@va... -Robert added file descriptor leakage checking, new library -interception machinery, support for client allocation pools, and minor -other tweakage. +Nick did the core/tool generalisation, wrote Cachegrind and Massif, +and tons of other stuff. + +Paul Mackerras + +Paul did a lot of the initial per-architecture factoring that forms +the basis of the 3.0 line and is also to be seen in 2.4.0. He also did +UCode-based dynamic translation support for PowerPC, and created a set +of ppc-linux derivatives of the 2.X release line. Dirk Mueller, dm...@gm... @@ -36,4 +31,17 @@ Keeper of the very excellent http://www.valgrind.org. +Julian Seward, ju...@va... + +Julian was the original designer and author of Valgrind, created the +dynamic translation framework, wrote Memcheck and Addrcheck, and did +lots of other things. + +Robert Walsh, rj...@va... + +Robert added file descriptor leakage checking, new library +interception machinery, support for client allocation pools, and minor +other tweakage. + + Frederic Gobry helped with autoconf and automake. Daniel Berlin modified readelf's dwarf2 source line reader, written by Nick Clifton, |
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 13:04:55
|
SVN commit 410018 by nethercote: Test change; whitespace-only M +1 -1 trunk/valgrind/TODO =20 --- trunk/valgrind/TODO #410017:410018 @@ -1,4 +1,4 @@ - +=20 Doesn't run ~~~~~~~~~~~ User Mode Linux. |
|
From: Nicholas N. <nj...@cs...> - 2005-05-17 03:23:55
|
SVN commit 414830 by nethercote:
Update website address.
MERGED FROM 3.0 REPOSITORY
M +1 -1 trunk/valgrind/README =20
M +1 -1 trunk/valgrind/README_MISSING_SYSCALL_OR_IOCTL =20
M +1 -1 trunk/valgrind/README_PACKAGERS =20
M +1 -1 trunk/valgrind/cachegrind/docs/cg_techdocs.html =20
M +1 -1 trunk/valgrind/coregrind/docs/coregrind_core.html =20
M +1 -1 trunk/valgrind/include/basic_types.h =20
M +1 -1 trunk/valgrind/memcheck/docs/mc_techdocs.html =20
M +1 -1 trunk/valgrind/none/tests/cmdline1.stdout.exp =20
M +1 -1 trunk/valgrind/none/tests/cmdline2.stdout.exp =20
--- trunk/valgrind/README #414829:414830
@@ -87,7 +87,7 @@
=20
6. See if it works. Try "valgrind --tool=3Dmemcheck ls -l". Either
this works, or it bombs out with some complaint. In that case,
- please let us know (see valgrind.kde.org/bugs.html).
+ please let us know (see www.valgrind.org).
=20
Important! Do not move the valgrind installation into a place
different from that specified by --prefix at build time. This will
--- trunk/valgrind/README_MISSING_SYSCALL_OR_IOCTL #414829:414830
@@ -166,5 +166,5 @@
more specific case to get the right behaviour.
=20
As above, please create a bug report and attach the patch as described
-on http://valgrind.kde.org/bugs.html
+on http://www.valgrind.org.
=20
--- trunk/valgrind/README_PACKAGERS #414829:414830
@@ -63,4 +63,4 @@
=20
=20
If you find any more hints/tips for packaging, please report
-it as a bugreport. See http://valgrind.kde.org/bugs.html for details.
+it as a bugreport. See http://www.valgrind.org for details.
--- trunk/valgrind/cachegrind/docs/cg_techdocs.html #414829:414830
@@ -33,7 +33,7 @@
<p>
<a href=3D"mailto:nj...@ca...">nj...@ca...</a><br>
<a
-href=3D"http://valgrind.kde.org">http://valgrind.kde.org</a><br>
+href=3D"http://www.valgrind.org">http://www.valgrind.org</a><br>
<p>
Copyright © 2001-2003 Nick Nethercote
<p>
--- trunk/valgrind/coregrind/docs/coregrind_core.html #414829:414830
@@ -1168,7 +1168,7 @@
=20
<a name=3D"problems"></a>
<h3>2.11 If you have problems</h3>
-Contact us at <a href=3D"http://valgrind.kde.org">valgrind.kde.org</a>.
+Contact us at <a href=3D"http://www.valgrind.org">www.valgrind.org</a>.
=20
<p>See <a href=3D"#limits">this section</a> for the known limitations of
Valgrind, and for a list of programs which are known not to work on
--- trunk/valgrind/include/basic_types.h #414829:414830
@@ -67,7 +67,7 @@
Where to send bug reports to.
------------------------------------------------------------------ */
=20
-#define VG_BUGS_TO "valgrind.kde.org"
+#define VG_BUGS_TO "www.valgrind.org"
=20
=20
#endif /* __BASIC_TYPES_H */
--- trunk/valgrind/memcheck/docs/mc_techdocs.html #414829:414830
@@ -33,7 +33,7 @@
These notes pertain to snapshot 20020306<br>
<p>
<a href=3D"mailto:js...@ac...">js...@ac...</a><br>
-<a href=3D"http://valgrind.kde.org">http://valgrind.kde.org</a><br>
+<a href=3D"http://www.valgrind.org">http://www.valgrind.org</a><br>
Copyright © 2000-2004 Julian Seward
<p>
Valgrind is licensed under the GNU General Public License,=20
--- trunk/valgrind/none/tests/cmdline1.stdout.exp #414829:414830
@@ -37,7 +37,7 @@
=20
Valgrind is Copyright (C) 2000-2005 Julian Seward et al.
and licensed under the GNU General Public License, version 2.
- Bug reports, feedback, admiration, abuse, etc, to: valgrind.kde.org.
+ Bug reports, feedback, admiration, abuse, etc, to: www.valgrind.org.
=20
Tools are copyright and licensed by their authors. See each
tool's start-up message for more information.
--- trunk/valgrind/none/tests/cmdline2.stdout.exp #414829:414830
@@ -59,7 +59,7 @@
=20
Valgrind is Copyright (C) 2000-2005 Julian Seward et al.
and licensed under the GNU General Public License, version 2.
- Bug reports, feedback, admiration, abuse, etc, to: valgrind.kde.org.
+ Bug reports, feedback, admiration, abuse, etc, to: www.valgrind.org.
=20
Tools are copyright and licensed by their authors. See each
tool's start-up message for more information.
|
|
From: Robert W. <rj...@du...> - 2005-05-30 02:03:54
|
SVN commit 419608 by rjwalsh: Update the ignore stuff so svn status doesn't complain so much. _M trunk/valgrind (directory) =20 _M addrcheck (directory) =20 _M auxprogs (directory) =20 _M cachegrind (directory) =20 _M cachegrind/tests (directory) =20 _M cachegrind/x86 (directory) =20 _M corecheck (directory) =20 _M corecheck/tests (directory) =20 _M coregrind (directory) =20 _M coregrind/demangle (directory) =20 _M coregrind/linux (directory) =20 _M coregrind/x86 (directory) =20 _M coregrind/x86-linux (directory) =20 _M helgrind (directory) =20 _M helgrind/tests (directory) =20 _M include (directory) =20 _M lackey (directory) =20 _M massif (directory) =20 _M massif/hp2ps (directory) =20 _M memcheck (directory) =20 _M memcheck/tests (directory) =20 _M memcheck/tests/x86 (directory) =20 _M none (directory) =20 _M none/tests (directory) =20 _M none/tests/x86 (directory) =20 _M tests (directory) =20 |
|
From: Nicholas N. <nj...@cs...> - 2005-06-02 03:48:59
|
SVN commit 421064 by nethercote:
Made VG_(atoll36) less flexible -- it now only does base-36 numbers
instead of any base in the range 2..36, since base-36 is the only one we
need. As part of that, I fixed a horrible bug in it which caused it to
return incorrect answers for any base-36 number containing the digits=20
'A'..'I'! (Eg. for "A" it would return 17 instead of 10!)
MERGED FROM 3.0 REPOSITORY
M +1 -1 coregrind/demangle/cp-demangle.c =20
M +9 -11 coregrind/vg_mylibc.c =20
M +2 -2 include/tool.h.base =20
--- trunk/valgrind/coregrind/demangle/cp-demangle.c #421063:421064
@@ -1408,7 +1408,7 @@
}
=20
if (base =3D=3D 36) {
- *value =3D VG_(atoll36) (36, dyn_string_buf (number));
+ *value =3D VG_(atoll36) (dyn_string_buf (number));
} else {
*value =3D VG_(atoll) (dyn_string_buf (number));
}
--- trunk/valgrind/coregrind/vg_mylibc.c #421063:421064
@@ -760,26 +760,23 @@
return n;
}
=20
-Long VG_(atoll36) ( UInt base, Char* str )
+Long VG_(atoll36) ( Char* str )
{
Bool neg =3D False;
Long n =3D 0;
- vg_assert(base >=3D 2 && base <=3D 36);
if (*str =3D=3D '-') { str++; neg =3D True; };
while (True) {
- if (*str >=3D '0'=20
- && *str <=3D (Char)('9' - (10 - base))) {
- n =3D base*n + (Long)(*str - '0');
+ Char c =3D *str;
+ if (c >=3D '0' && c <=3D (Char)'9') {
+ n =3D 36*n + (Long)(c - '0');
}
else=20
- if (base > 10 && *str >=3D 'A'=20
- && *str <=3D (Char)('Z' - (36 - base))) {
- n =3D base*n + (Long)((*str - 'A') + 10);
+ if (c >=3D 'A' && c <=3D (Char)'Z') {
+ n =3D 36*n + (Long)((c - 'A') + 10);
}
else=20
- if (base > 10 && *str >=3D 'a'=20
- && *str <=3D (Char)('z' - (36 - base))) {
- n =3D base*n + (Long)((*str - 'a') + 10);
+ if (c >=3D 'a' && c <=3D (Char)'z') {
+ n =3D 36*n + (Long)((c - 'a') + 10);
}
else {
break;
@@ -791,6 +788,7 @@
}
=20
=20
+
Char* VG_(strcat) ( Char* dest, const Char* src )
{
Char* dest_orig =3D dest;
--- trunk/valgrind/include/tool.h.base #421063:421064
@@ -382,8 +382,8 @@
/* Like atoll(), but converts a number of base 16 */
extern Long VG_(atoll16) ( Char* str );
=20
-/* Like atoll(), but converts a number of base 2..36 */
-extern Long VG_(atoll36) ( UInt base, Char* str );
+/* Like atoll(), but converts a number of base 36 */
+extern Long VG_(atoll36) ( Char* str );
=20
/* Like qsort(), but does shell-sort. The size=3D=3D1/2/4 cases are spe=
cialised. */
extern void VG_(ssort)( void* base, SizeT nmemb, SizeT size,
|
|
From: Robert W. <rj...@du...> - 2005-06-04 21:04:21
|
SVN commit 422246 by rjwalsh: Implement stack registration client requests. See the documentation in coregrind_core.html for details. There's a sample program in stack_changes.c in corecheck/tests. _M corecheck/tests (directory) =20 M +4 -2 corecheck/tests/Makefile.am =20 A corecheck/tests/stack_changes.c [License: no copyright] A corecheck/tests/stack_changes.stderr.exp =20 A corecheck/tests/stack_changes.stdout.exp =20 A corecheck/tests/stack_changes.vgtest =20 M +5 -0 coregrind/core.h =20 M +20 -0 coregrind/docs/coregrind_core.html =20 M +6 -0 coregrind/vg_main.c =20 M +184 -1 coregrind/vg_memory.c =20 M +15 -0 coregrind/vg_scheduler.c =20 M +4 -0 coregrind/vg_signals.c =20 M +32 -1 include/valgrind.h.in =20 |
|
From: Tom H. <th...@cy...> - 2005-07-18 14:14:04
|
SVN commit 435880 by thughes:
Backport fixes for bugs #103509, #106293, #104797, #101881 from
the valgrind 3.0 tree.
M +1 -0 coregrind/core.h =20
M +1 -1 coregrind/vg_memory.c =20
M +2 -2 coregrind/vg_mylibc.c =20
M +17 -10 coregrind/vg_syscalls.c =20
M +1 -0 include/linux/vki.h =20
--- trunk/valgrind/coregrind/core.h #435879:435880
@@ -887,6 +887,7 @@
const Char *val );
extern void VG_(env_unsetenv) ( Char **env, const Char *varname );
extern void VG_(env_remove_valgrind_env_stuff) ( Char** env );=20
+extern Char **VG_(env_clone) ( Vhar **envp );
=20
extern void VG_(nanosleep)(struct vki_timespec *);
/* ---------------------------------------------------------------------
--- trunk/valgrind/coregrind/vg_memory.c #435879:435880
@@ -1014,7 +1014,7 @@
=20
for(s =3D VG_(first_segment)(); s !=3D NULL; s =3D VG_(next_segment)(=
s)) {
UInt flags =3D s->flags & (SF_SHARED|SF_MMAP|SF_VALGRIND|SF_CORE|S=
F_STACK|SF_DEVICE);
- if (flags !=3D SF_MMAP && flags !=3D SF_STACK)
+ if (flags !=3D SF_MMAP && flags !=3D SF_STACK && flags !=3D (SF_MM=
AP|SF_STACK))
continue;
if ((s->prot & (VKI_PROT_READ|VKI_PROT_WRITE)) !=3D (VKI_PROT_READ=
|VKI_PROT_WRITE))
continue;
--- trunk/valgrind/coregrind/vg_mylibc.c #435879:435880
@@ -1356,7 +1356,7 @@
------------------------------------------------------------------ */
=20
/* clone the environment */
-static Char **env_clone ( Char **oldenv )
+Char **VG_(env_clone) ( Char **oldenv )
{
Char **oldenvp;
Char **newenvp;
@@ -1640,7 +1640,7 @@
/* restore the DATA rlimit for the child */
VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
=20
- envp =3D env_clone(VG_(client_envp));
+ envp =3D VG_(env_clone)(VG_(client_envp));
VG_(env_remove_valgrind_env_stuff)( envp );=20
=20
argv[0] =3D "/bin/sh";
--- trunk/valgrind/coregrind/vg_syscalls.c #435879:435880
@@ -1697,6 +1697,7 @@
PRE(sys_execve, Special)
{
Char *path; /* path to executable */
+ Char **envp; /* environment */
=20
PRINT("sys_execve ( %p(%s), %p, %p )", arg1, arg1, arg2, arg3);
PRE_REG_READ3(vki_off_t, "execve",
@@ -1746,16 +1747,14 @@
VG_(shutdown_actions)(tid);
}
=20
- {
- // Remove the valgrind-specific stuff from the environment so the
- // child doesn't get vg_inject.so, vgpreload.so, etc. This is
- // done unconditionally, since if we are tracing the child,
- // stage1/2 will set up the appropriate client environment.
- Char** envp =3D (Char**)arg3;
+ // Remove the valgrind-specific stuff from the environment so the
+ // child doesn't get vg_inject.so, vgpreload.so, etc. This is
+ // done unconditionally, since if we are tracing the child,
+ // stage1/2 will set up the appropriate client environment.
+ envp =3D VG_(env_clone)( (Char**)arg3 );
=20
- if (envp !=3D NULL) {
- VG_(env_remove_valgrind_env_stuff)( envp );=20
- }
+ if (envp !=3D NULL) {
+ VG_(env_remove_valgrind_env_stuff)( envp );=20
}
=20
if (VG_(clo_trace_children)) {
@@ -3269,6 +3268,9 @@
case VKI_BLKGETSIZE:
SYS_PRE_MEM_WRITE( "ioctl(BLKGETSIZE)", arg3, sizeof(unsigned long=
));
break;
+ case VKI_BLKGETSIZE64:
+ SYS_PRE_MEM_WRITE( "ioctl(BLKGETSIZE64)", arg3, sizeof(unsigned lo=
ng long));
+ break;
=20
/* Hard disks */
case VKI_HDIO_GET_IDENTITY: /* 0x030d */
@@ -3934,6 +3936,9 @@
case VKI_BLKGETSIZE:
VG_TRACK( post_mem_write,arg3, sizeof(unsigned long));
break;
+ case VKI_BLKGETSIZE64:
+ VG_TRACK( post_mem_write,arg3, sizeof(unsigned long long));
+ break;
=20
/* Hard disks */
case VKI_HDIO_GET_IDENTITY: /* 0x030d */
@@ -5423,7 +5428,9 @@
{
PRINT("sys_times ( %p )", arg1);
PRE_REG_READ1(long, "times", struct tms *, buf);
- SYS_PRE_MEM_WRITE( "times(buf)", arg1, sizeof(struct vki_tms) );
+ if (arg1 !=3D 0) {
+ SYS_PRE_MEM_WRITE( "times(buf)", arg1, sizeof(struct vki_tms) );
+ }
}
=20
POST(sys_times)
--- trunk/valgrind/include/linux/vki.h #435879:435880
@@ -1390,6 +1390,7 @@
//----------------------------------------------------------------------
=20
#define VKI_BLKGETSIZE _VKI_IO(0x12,96) /* return device size /512 (long=
*arg) */
+#define VKI_BLKGETSIZE64 _VKI_IOR(0x12,114, vki_size_t) /* return device=
size in bytes (u64 *arg) */
=20
#define VKI_FIBMAP _VKI_IO(0x00,1) /* bmap access */
#define VKI_FIGETBSZ _VKI_IO(0x00,2) /* get the block size used for b=
map */
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 14:44:32
|
On Mon, 18 Jul 2005, Tom Hughes wrote: > SVN commit 435880 by thughes: > > Backport fixes for bugs #103509, #106293, #104797, #101881 from > the valgrind 3.0 tree. Julian is thinking about doing a 3.0 release soon, ie. doing a release candidate in the next week or so. Dirk volunteered to do a 2.4.1 release, but there doesn't seem to be much desire for it, and I think any effort would be better put towards the 3.0 release, because 2.4.1 doesn't have that many improvements over 2.4.0. I think most people will want 3.0, especially for AMD64 support. ---- On a related note, I'd like to propose that we change the way we number and do releases. Previously we've followed the old Linux kernel scheme where even-numbered releases (2.2.X, 2.4.X, etc) are "stable", and odd-numbered release (2.1.X, 2.3.X, etc) are "development" releases. Only bug-fixes go into stable lines. I think this isn't working very well. The stable releases get old and boring too quickly, and interesting stuff goes into the development releases. We never had a 2.0.1 or 2.2.1 release, and I don't think we need a 2.4.1. We invariably recommend the development releases over the stable releases, saying "although it is a development release, it's much better than the last stable release". I suggest we abandon the even/odd numbering scheme, and partially abandon the stable/development split. I think we'd increase the minor-minor version (eg. 3.0.0 to 3.0.1) for releases that have not-too-big changes (ie. allow more than just bug fixes in them), and increase the minor version (eg. 3.0.1 to 3.1.0) for bigger changes. What constitutes a bigger change? I guess things like Jeremy's FV memory reworking or libpthread-removal. Things where it's conceivable that we might want to undo a big change if it doesn't work out. In those cases we could maintain a temporary stable/development split (eg. 3.0.1/3.1.0) until the new feature has had time to settle in. Overall this would be more like the GCC release model, although not as formal and we wouldn't maintain older branches nearly as long (eg. they're still doing releases like 3.3.6 even though 3.4.X and 4.0.X have been released). How does that sound? N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 15:50:38
|
On Mon, 18 Jul 2005, Tom Hughes wrote: >> Julian is thinking about doing a 3.0 release soon, ie. doing a release >> candidate in the next week or so. > > I think there are few things that we need to think about before a > release - there is the question of whether or not to integrate vex > which I emailed Julian about a week or so back and also issues about > packaging and support for 32 bit binaries on 64 bit systems which > Robert raised on the list recently. > > I've got one other issue on 64 bit systems that I need to look at > and we should probably have a look at what bugs are outstanding as > we've been concentrating more on the question of getting 3.0 more > or less working of late. It's a good point -- what does need to be done for 3.0? Here's my list: - Better Vex integration (ideally, users don't need to know about Vex at all when installing) - SegInfos currently are not deallocated properly, this should be fixed. - Addrcheck isn't working. Would be good if it did, but I can't see it happening any time soon. What other things should be added to this list? N |
|
From: Dirk M. <dm...@gm...> - 2005-07-18 16:07:52
|
On Monday 18 July 2005 16:44, Nicholas Nethercote wrote: > Dirk volunteered to do a 2.4.1 release, but there doesn't seem to be much > desire for it Well, just a couple of outstanding bug fixes. > and I think any effort would be better put towards the 3.0 > release, because 2.4.1 doesn't have that many improvements over 2.4.0. I > think most people will want 3.0, especially for AMD64 support. Remember that valgrind is used outside the repository as well, there are a few additional "tools" using the valgrind core machinery, e.g. kcachegrind. It will take a while until they're ported and stable with valgrind 3.0 - let alone valgrind 3.0 become stable. Therefore, I think maintaining 2.4.x is still a worthy goal, even if nothing interesting happens there. Thats okay. As long as a bugfix is as much work as applying a multiline trivial patch, thats fine. Also, I volunteered to do a 2.4.x release cycle because its important for distributors to pick up fixes. > I think this isn't working very well. The stable releases get old and > boring too quickly, and interesting stuff goes into the development > releases. We never had a 2.0.1 or 2.2.1 release, and I don't think we > need a 2.4.1. Remember the tool-interface. tool-interface changes should happen in the development branch. > How does that sound? I don't see the difference. BTW, gcc's release model is far more driven by people / vendors only wanting the bugfixes, but not the new features (which are likely to introduce regressions). Also, they have a testsuite to validate which fixes from trunk need backporting. How that matches with the idea of abandoning the stable branch? No idea. If anything, then the valgrind development model is more linux like than gcc like. how much changes do you see in linux 2.2.x these days? nothing besides urgent security fixes or major data loss bugs. Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 15:58:46
|
On Tue, 19 Jul 2005, Tom Hughes wrote: >>>> I have a patch to default to using a vex in the top level valgrind >>>> directory. It also fixes valgrind's makefiles to build vex if necessary. >>>> Combining that with a subversion external so that vex is checked out >>>> with valgrind should provide a solution. How does the Subversion external work? N |
|
From: Tom H. <to...@co...> - 2005-07-18 15:19:23
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Mon, 18 Jul 2005, Tom Hughes wrote:
>
>> SVN commit 435880 by thughes:
>>
>> Backport fixes for bugs #103509, #106293, #104797, #101881 from
>> the valgrind 3.0 tree.
>
> Julian is thinking about doing a 3.0 release soon, ie. doing a release
> candidate in the next week or so.
I think there are few things that we need to think about before a
release - there is the question of whether or not to integrate vex
which I emailed Julian about a week or so back and also issues about
packaging and support for 32 bit binaries on 64 bit systems which
Robert raised on the list recently.
I've got one other issue on 64 bit systems that I need to look at
and we should probably have a look at what bugs are outstanding as
we've been concentrating more on the question of getting 3.0 more
or less working of late.
> I suggest we abandon the even/odd numbering scheme, and partially
> abandon the stable/development split. I think we'd increase the
> minor-minor version (eg. 3.0.0 to 3.0.1) for releases that have
> not-too-big changes (ie. allow more than just bug fixes in them), and
> increase the minor version (eg. 3.0.1 to 3.1.0) for bigger changes.
> What constitutes a bigger change? I guess things like Jeremy's FV
> memory reworking or libpthread-removal. Things where it's conceivable
> that we might want to undo a big change if it doesn't work out. In
> those cases we could maintain a temporary stable/development split
> (eg. 3.0.1/3.1.0) until the new feature has had time to settle in.
This sounds like a reasonable idea.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-07-18 16:38:00
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> It's a good point -- what does need to be done for 3.0? Here's my list:
>
> - Better Vex integration (ideally, users don't need to know about Vex at
> all when installing)
I have a patch to default to using a vex in the top level valgrind
directory. It also fixes valgrind's makefiles to build vex if necessary.
Combining that with a subversion external so that vex is checked out
with valgrind should provide a solution.
> - Addrcheck isn't working. Would be good if it did, but I can't see it
> happening any time soon.
I think it should be fairly easy to re-enable - it was only disabled
to make things easier while getting memcheck going. Most of the hard
work is shared with the memcheck code anyway.
Didn't Julian talk about dropping addrcheck though as it didn't seem
to have much point?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 18:11:34
|
On Mon, 18 Jul 2005, Tom Hughes wrote: > I have a patch to default to using a vex in the top level valgrind > directory. It also fixes valgrind's makefiles to build vex if necessary. > > Combining that with a subversion external so that vex is checked out > with valgrind should provide a solution. Sounds good. >> - Addrcheck isn't working. Would be good if it did, but I can't see it >> happening any time soon. > > I think it should be fairly easy to re-enable - it was only disabled > to make things easier while getting memcheck going. Most of the hard > work is shared with the memcheck code anyway. I think it will be harder than you think. > Didn't Julian talk about dropping addrcheck though as it didn't seem > to have much point? My opinion was that this would be fine if/when we implement the compressed V-bit representation for Memcheck, but that currently Addrcheck is useful to have for people who have programs that use lots of memory. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 01:13:57
|
>> I have a patch to default to using a vex in the top level valgrind >> directory. It also fixes valgrind's makefiles to build vex if necessary. >> >> Combining that with a subversion external so that vex is checked out >> with valgrind should provide a solution. > > Sounds good. Can you post the patch to the list? I'm interested to see what it looks like. Thanks. N |
|
From: Tom H. <to...@co...> - 2005-07-19 07:48:12
Attachments:
valgrind-vex.patch
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
>>> I have a patch to default to using a vex in the top level valgrind
>>> directory. It also fixes valgrind's makefiles to build vex if necessary.
>>> Combining that with a subversion external so that vex is checked out
>>> with valgrind should provide a solution.
>>
>> Sounds good.
>
> Can you post the patch to the list? I'm interested to see what it
> looks like.
Attached - it isn't very complicated, and a few improvement to vex's
makefile that I suggested to Julian would probably make it even simpler.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 15:26:12
|
On Tue, 19 Jul 2005, Tom Hughes wrote: >>>> I have a patch to default to using a vex in the top level valgrind >>>> directory. > > Attached - it isn't very complicated, and a few improvement to vex's > makefile that I suggested to Julian would probably make it even simpler. What does this do? +libvex_guest_offsets.h: + $(MAKE) -C @VEX_DIR@ pub/libvex_guest_offsets.h Thanks. N |
|
From: Tom H. <to...@co...> - 2005-07-19 15:32:06
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 19 Jul 2005, Tom Hughes wrote:
>
>>>>> I have a patch to default to using a vex in the top level valgrind
>>>>> directory.
>>
>> Attached - it isn't very complicated, and a few improvement to vex's
>> makefile that I suggested to Julian would probably make it even simpler.
>
> What does this do?
>
> +libvex_guest_offsets.h:
> + $(MAKE) -C @VEX_DIR@ pub/libvex_guest_offsets.h
It ensures that libvex_guest_offsets.h (which is built by genoffsets
and is not in the repository) is up to date.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 15:38:49
|
On Tue, 19 Jul 2005, Tom Hughes wrote:
>> What does this do?
>>
>> +libvex_guest_offsets.h:
>> + $(MAKE) -C @VEX_DIR@ pub/libvex_guest_offsets.h
>
> It ensures that libvex_guest_offsets.h (which is built by genoffsets
> and is not in the repository) is up to date.
Ah. libvex_guest_offsets.h contains code that looks like this:
#define OFFSET_x86_EAX 0
#define OFFSET_x86_EBX 12
and is generated by code that looks like this:
printf("#define OFFSET_x86_EAX %3d\n",
offsetof(VexGuestX86State,guest_EAX));
printf("#define OFFSET_x86_EBX %3d\n",
offsetof(VexGuestX86State,guest_EBX));
AFAICT the only user of these constants is
coregrind/m_syswrap/syswrap-main.c, and libvex_guest_offsets.h could be
changed to this:
#define OFFSET_x86_EAX offsetof(VexGuestX86State,guest_EAX));
#define OFFSET_x86_EBX offsetof(VexGuestX86State,guest_EBX));
and then we wouldn't need to autogenerate libvex_guest_offsets.h which
would make things simpler. Am I missing anything here?
N
|
|
From: Tom H. <to...@co...> - 2005-07-19 15:46:34
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> Ah. libvex_guest_offsets.h contains code that looks like this:
>
> #define OFFSET_x86_EAX 0
> #define OFFSET_x86_EBX 12
>
> and is generated by code that looks like this:
>
> printf("#define OFFSET_x86_EAX %3d\n",
> offsetof(VexGuestX86State,guest_EAX));
>
> printf("#define OFFSET_x86_EBX %3d\n",
> offsetof(VexGuestX86State,guest_EBX));
>
>
> AFAICT the only user of these constants is
> coregrind/m_syswrap/syswrap-main.c,
and the .S files in m_syswrap and m_dispatch.
> and libvex_guest_offsets.h could be changed to this:
>
> #define OFFSET_x86_EAX offsetof(VexGuestX86State,guest_EAX));
> #define OFFSET_x86_EBX offsetof(VexGuestX86State,guest_EBX));
>
> and then we wouldn't need to autogenerate libvex_guest_offsets.h which
> would make things simpler. Am I missing anything here?
I don't that will work for the assembler files.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-07-19 16:48:44
|
> > #define OFFSET_x86_EAX offsetof(VexGuestX86State,guest_EAX)); > > #define OFFSET_x86_EBX offsetof(VexGuestX86State,guest_EBX)); > > > > and then we wouldn't need to autogenerate libvex_guest_offsets.h which > > would make things simpler. Am I missing anything here? > > I don't that will work for the assembler files. Yeh, it's the .S files that cause the problem. J |
|
From: Tom H. <to...@co...> - 2005-07-19 16:47:52
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 19 Jul 2005, Tom Hughes wrote:
>
> >>>> I have a patch to default to using a vex in the top level valgrind
> >>>> directory. It also fixes valgrind's makefiles to build vex if necessary.
> >>>> Combining that with a subversion external so that vex is checked out
> >>>> with valgrind should provide a solution.
>
> How does the Subversion external work?
You create an svn:externals property on the parent directory listing
other things which should be checked out when that directory is checked
out.
So in this case we would create an svn:externals property on the top
level directory of valgrind that contained:
vex svn://svn.valgrond.org/vex/trunk
That would cause vex to be checked out into the vex subdirectory whenever
valgrind was checked out, and likewise for updates and so on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 16:56:22
|
On Tue, 19 Jul 2005, Tom Hughes wrote: > You create an svn:externals property on the parent directory listing > other things which should be checked out when that directory is checked > out. > > So in this case we would create an svn:externals property on the top > level directory of valgrind that contained: > > vex svn://svn.valgrond.org/vex/trunk > > That would cause vex to be checked out into the vex subdirectory whenever > valgrind was checked out, and likewise for updates and so on. Neat! I'd be happy for this external to be created, and Tom's Makefile.am patch to go in. Any objections? N ps: Valgrond, eh? I like it :) |