|
From: Julian S. <js...@ac...> - 2005-11-01 18:25:12
|
Greetings. It's once again time for the major-release fun 'n' games.
I'm proposing we make a first release candidate on Friday 18 Nov, with
final release as soon as possible after that, and not later than
Friday 25 Nov, unless something really nasty turns up.
3.1.0 will support {x86,amd64,ppc32}-linux. It will contain the new
address space manager (a.k.a proper 64-bit support), a usable
ppc32-linux port, and many many small fixes relative to 3.0.1.
Larger stuff that needs to be sorted before the RC:
* Tom's biarch stuff
* ppc Altivec support
* coordinate with JosefW so as to have a simultaneous matching
callgrind/kcachegrind release if possible
* fix timestamping to show wallclock time elapsed since the run
started, since it looks like reimplementing localtime_r is
pretty much a non-starter.
Smaller stuff:
* check interface versioning
* reinstate --partial-loads-ok for memcheck
* possible have a --definedness-errors=no flag for mc, to make it
look like addrcheck
* install libcoregrind.a (needed for external tools)
* add ppc32 instruction test program to the testsuite
* fix various missing instructions
What else?
Overall I think the code base is in pretty good shape. The master
bug-status list is kept in docs/internals/3_0_BUGSTATUS.txt.
Please let me know of any stability problems you know of. I have had
OOo crashing on V on some ppc32 distros, which I should look into.
Closer to the time, I'll trawl through regtest failures on machines I
have access to see if there's anything critical there. It would be
helpful if others could do likewise.
J
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-11-01 20:36:32
Attachments:
pointer-trace.stderr.diff
mremap2.stdout.diff
|
> Closer to the time, I'll trawl through regtest failures on machines I > have access to see if there's anything critical there. It would be > helpful if others could do likewise. The regression test on Debian 3.1 (sarge) with valgrind revision 4979, VEX revision 1427 results in six failures. 1. The most serieus seem to be the error in memcheck/tests/pointer-trace and none/tests/mremap2. (These appeared after the merging in of the ASPACEM branch. (Previously reported on 1 October.)) See attached files memcheck/tests/pointer-trace.stderr.diff and none/tests/mremap2.stdout.diff. 2. AFAIK, the failures of none/tests/faultstatus and none/tests/x86/int are current restrictions in VEX. 3. The failures of memcheck/tests/writev and none/tests/fdleak_fcntl can be fixed with additional .exp files. $ uname -a: Linux DoornRoosje 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux $ gcc -v: gcc version 3.3.5 (Debian 1:3.3.5-13) Jeroen. |
|
From: Julian S. <js...@ac...> - 2005-11-11 19:55:06
|
We've made good progress this past couple of weeks. Many loose ends have
been cleared up and it's looking good. I think we're still on track for a
RC next Friday (18th). The current status is:
> * Tom's biarch stuff
Done.
> * ppc Altivec support
Largely done.
> * coordinate with JosefW so as to have a simultaneous matching
> callgrind/kcachegrind release if possible
Pretty much done. callgrind appears to be working stably with the
svn head on all 3 archs now.
> * fix timestamping to show wallclock time elapsed since the run
> started, since it looks like reimplementing localtime_r is
> pretty much a non-starter.
Done.
------------
Stuff that still needs to happen before we're feature complete.
Please feel free to push any of these along :-)
- a trawl through the docs, to bring it up to date, and to fix broken
HTML links
- update the man page
- fix easy-to-fix regtests
- bring docs/internals/3_0_BUGSTATUS.txt up to date, as that is the
basis from which the fixed-bugs list on the final announcement
is made. Also, check there isn't anything critical on bugzilla
we missed.
- create a comprehensive list of all the user-visible stuff we've
changed/enhanced.
Lower priority things which would be nice to include, but are not
critical:
- more Altivec tests and insns.
- handle x86 clflush insn
- print closing </valgrindoutput> in XML mode if a failure occurs.
- look at $PATH expansion problem when handling !# scripts.
- fix none/tests/ppc32/jm-insns.c so it works with gcc4.
- write a test tool which uses a helper fn which trashes all
the registers it legitimately can, and see what breaks. I suspect
vex isn't saving enough state around helper function calls.
- Nick found a nasty-looking performance problem with memcheck.
- see if it can be made to work on ppc405/ppc440.
------------
I've been keeping a note of the tests I'd like to run before RC1 and
ideally again on the final tarball. There are a lot of tests, and so
any help in running them -- on the code base as it stands right now --
would be really appreciated.
- Check it builds and regtests on a vanilla gcc-2.96 / RedHat 7.3 distro.
Also check that callgrind buids/installs alongside it OK.
- Check standard build and regtest on the following cpus:
x86, sse2 (P4)
x86, sse1 (PIII)
x86, no sse (eg older VIA C3s, or perhaps even Pentium-MMX)
amd64
ppc32, altivec
ppc32, no altivec (eg old iMac G3s)
- Check that the regression tests work with --sanity-level=4 on all
platforms.
- Check valgrind-listener works on all archs, also connecting to it
from all archs
- Check memcheck can run all the insn-set tests. The testsuite
only runs those on 'none', but memcheck looks at all primops, and I've
been caught out by this before. Basically all the programs in
none/tests/{x86,amd64,ppc32}.
- Check XML output is still readable by Valkyrie and vk_logmerge tools
- Test with large applications (firefox and OOo 2.0) on all platforms.
- Run regression tests from gsl-1.6 on all platforms. This is a good,
thorough test of FP. Easy, using the scripts auxprogs/gsl16test.
- Check that a tarball build of callgrind is buildable/installable
against a from-tarball build of valgrind.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-11 21:18:47
|
On Fri, 11 Nov 2005, Julian Seward wrote:
> I've been keeping a note of the tests I'd like to run before RC1 and
> ideally again on the final tarball. There are a lot of tests, and so
> any help in running them -- on the code base as it stands right now --
> would be really appreciated.
Nice list, we should add this to docs/internals/release-HOWTO.txt.
> - Check memcheck can run all the insn-set tests. The testsuite
> only runs those on 'none', but memcheck looks at all primops, and I've
> been caught out by this before. Basically all the programs in
> none/tests/{x86,amd64,ppc32}.
So let's just make Memcheck run those tests in the default suite?
Nick
|
|
From: Julian S. <js...@ac...> - 2005-11-11 22:25:29
|
> > - Check memcheck can run all the insn-set tests. The testsuite
> > only runs those on 'none', but memcheck looks at all primops, and I've
> > been caught out by this before. Basically all the programs in
> > none/tests/{x86,amd64,ppc32}.
>
> So let's just make Memcheck run those tests in the default suite?
Not sure what you mean. Is there some way to run them in memcheck
too, without laboriously moving all those files from none/tests
to memcheck/tests?
J
|
|
From: Tom H. <to...@co...> - 2005-11-13 17:03:07
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> - Check that the regression tests work with --sanity-level=4 on all
> platforms.
I've run this on x86 and amd64 and the only problem it found was
with corrupt device numbers being returned by kernel for x86 binaries
on amd64 causing the sync checker to fail. I've committed a fix to
work around that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-13 17:18:58
|
> > - Check that the regression tests work with --sanity-level=4 on all > > platforms. > > I've run this on x86 and amd64 and the only problem it found was > with corrupt device numbers being returned by kernel for x86 binaries > on amd64 causing the sync checker to fail. I've committed a fix to > work around that. That's great. Thanks. J |
|
From: Josef W. <Jos...@gm...> - 2005-11-11 21:35:02
|
On Friday 11 November 2005 20:56, Julian Seward wrote: > > * Tom's biarch stuff > > Done. Still unsolved: biarch for external tools? * Can valgrind.pc generation changed to include information for biarch installations? * Or install 2 valgrind.pc files, and the configure of the external tool checks for both a valgrind64.pc and valgrind.pc? > > * coordinate with JosefW so as to have a simultaneous matching > > callgrind/kcachegrind release if possible > > Pretty much done. callgrind appears to be working stably with the > svn head on all 3 archs now. Yes. But the call graph generation currently looks broken on ppc32. Some help with ppc assembler greatly appreciated regarding the best way to track function calls/returns. Josef |
|
From: Tom H. <to...@co...> - 2005-11-11 23:10:00
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Friday 11 November 2005 20:56, Julian Seward wrote:
> > > * Tom's biarch stuff
> >
> > Done.
>
> Still unsolved: biarch for external tools?
> * Can valgrind.pc generation changed to include information for
> biarch installations?
> * Or install 2 valgrind.pc files, and the configure of the
> external tool checks for both a valgrind64.pc and valgrind.pc?
I don't think pkgconfig has any support for dual architecture
systems so the latter is probably the best we can do. Nothing
else seems to bother that I have seen.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-11 23:07:28
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> > > - Check memcheck can run all the insn-set tests. The testsuite
> > > only runs those on 'none', but memcheck looks at all primops, and I've
> > > been caught out by this before. Basically all the programs in
> > > none/tests/{x86,amd64,ppc32}.
> >
> > So let's just make Memcheck run those tests in the default suite?
>
> Not sure what you mean. Is there some way to run them in memcheck
> too, without laboriously moving all those files from none/tests
> to memcheck/tests?
We used to do it in 2.4 so it should be possible. I'll have a look.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-12 00:16:52
|
In message <928...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
> > > > - Check memcheck can run all the insn-set tests. The testsuite
> > > > only runs those on 'none', but memcheck looks at all primops, and I've
> > > > been caught out by this before. Basically all the programs in
> > > > none/tests/{x86,amd64,ppc32}.
> > >
> > > So let's just make Memcheck run those tests in the default suite?
> >
> > Not sure what you mean. Is there some way to run them in memcheck
> > too, without laboriously moving all those files from none/tests
> > to memcheck/tests?
>
> We used to do it in 2.4 so it should be possible. I'll have a look.
What we did in 2.4 is to duplicate the vgtest and stdout.exp files
but make the vgtest point binaries in the none test area.
If that sounds alright then I'll reinstate it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-12 01:16:29
|
On Saturday 12 November 2005 00:16, Tom Hughes wrote:
> In message <928...@lo...>
>
> Tom Hughes <to...@co...> wrote:
> > In message <200...@ac...>
> >
> > Julian Seward <js...@ac...> wrote:
> > > > > - Check memcheck can run all the insn-set tests. The testsuite
> > > > > only runs those on 'none', but memcheck looks at all primops, and
> > > > > I've been caught out by this before. Basically all the programs in
> > > > > none/tests/{x86,amd64,ppc32}.
> > > >
> > > > So let's just make Memcheck run those tests in the default suite?
> > >
> > > Not sure what you mean. Is there some way to run them in memcheck
> > > too, without laboriously moving all those files from none/tests
> > > to memcheck/tests?
> >
> > We used to do it in 2.4 so it should be possible. I'll have a look.
>
> What we did in 2.4 is to duplicate the vgtest and stdout.exp files
> but make the vgtest point binaries in the none test area.
>
> If that sounds alright then I'll reinstate it.
I don't fancy duplicating those files -- is it possible to add soft
symlinks whilst not confusing svn?
J
|
|
From: Tom H. <to...@co...> - 2005-11-12 09:00:59
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Saturday 12 November 2005 00:16, Tom Hughes wrote:
>
> > What we did in 2.4 is to duplicate the vgtest and stdout.exp files
> > but make the vgtest point binaries in the none test area.
> >
> > If that sounds alright then I'll reinstate it.
>
> I don't fancy duplicating those files -- is it possible to add soft
> symlinks whilst not confusing svn?
It might be with SVN yes.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-12 01:17:35
|
On Saturday 12 November 2005 00:09, Tom Hughes wrote: > In message <200...@gm...> > Josef Weidendorfer <Jos...@gm...> wrote: > > > On Friday 11 November 2005 20:56, Julian Seward wrote: > > > > * Tom's biarch stuff > > > > > > Done. > > > > Still unsolved: biarch for external tools? > > * Can valgrind.pc generation changed to include information for > > biarch installations? > > * Or install 2 valgrind.pc files, and the configure of the > > external tool checks for both a valgrind64.pc and valgrind.pc? > > I don't think pkgconfig has any support for dual architecture > systems Why would pkgconfig fail to support some further variables in valgrind.pc? The major defined ones (Name/Description/Version) have the same value for both subarchitectures in our case. All the variables handled in any special way by pkg-config (Libs/Cflags) would describe the primary architecture (amd64 here), and for the secondary arch we define our own variable names, e.g. installtypes=2 arch=amd64 arch2=x86 platform2=x86-linux valt_load_address2=... Libs2=-L... -l... Cflags2=... Perhaps I am totally misusing pkgconfig here :-) BTW: I use my own 10-liner Perlscript to read the .pc file, so this is no problem... > so the latter is probably the best we can do. Nothing > else seems to bother that I have seen. I have the fear that with 2 pc files, distros will change the names to their convention (e.g. in valgrind-x86/amd64.pc or valgrind32/64.pc), and external tool installations will fail to detect these (if not part of the distro). Josef |
|
From: Tom H. <to...@co...> - 2005-11-12 09:00:55
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Saturday 12 November 2005 00:09, Tom Hughes wrote:
>
> > I don't think pkgconfig has any support for dual architecture
> > systems
>
> Why would pkgconfig fail to support some further variables in valgrind.pc?
> The major defined ones (Name/Description/Version) have the same
> value for both subarchitectures in our case.
> All the variables handled in any special way by pkg-config (Libs/Cflags)
> would describe the primary architecture (amd64 here), and for the
> secondary arch we define our own variable names, e.g.
>
> installtypes=2
> arch=amd64
> arch2=x86
> platform2=x86-linux
> valt_load_address2=...
> Libs2=-L... -l...
> Cflags2=...
Becasue how will "pkg-config --libs" know which variable to use...
Basically it will force every body to use --variable and do al the
heavy lifting themselves and mean that most of the command line
options in the pkg-config manual page won't work reliably.
I would go with valgrind-x86-linux.pc and valgrind-amd64-linux.pc
personally.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-13 21:24:21
|
On Saturday 12 November 2005 08:46, Tom Hughes wrote: > > installtypes=2 > > arch=amd64 > > arch2=x86 > > platform2=x86-linux > > valt_load_address2=... > > Libs2=-L... -l... > > Cflags2=... > > Becasue how will "pkg-config --libs" know which variable to use... > > Basically it will force every body to use --variable and do al the > heavy lifting themselves and mean that most of the command line > options in the pkg-config manual page won't work reliably. Ok, convinced ;-) > I would go with valgrind-x86-linux.pc and valgrind-amd64-linux.pc > personally. Good. Josef > > Tom > |