|
From: Julian S. <js...@ac...> - 2013-05-02 10:18:55
|
Greetings.
It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out
in the next two months or so. I'd like to propose a freeze date of
Friday 31 May (all new features/fixes should be in by then), and a two
week stabilisation/test period, ending in release, on Friday 14 June.
Considering the stuff still to do (see below), that might be a little
ambitious -- I don't know.
How does that sound? Any counter-proposals? Any other stuff-to-fix?
s390, MIPS and POWER folks, do the proposed dates work for you?
>From a quick look through the NEWS file, new stuff since 3.8.0 is:
- mips64-linux port
- avx2 support
- better control of leak reporting: --show-leak-kinds,
--errors-for-leak-kinds
- better control of block stack traces: --keep-stacktraces
- merge recursive frames in stack unwind: --merge-recursive-frames=
- more GDBserver monitor commands
- greatly improved arm neon load/store performance
- introduction of direct IR support for conditional loads and stores [1]
- use [1] for representing ARM conditional loads/stores [2]
- lots of bugs fixed
- more ppc and zSeries DFP support (?)
If there's stuff I missed there, please add it to the NEWS file.
There's still a number of things I'd like to get fixed before release.
- make avx/avx2 conditional loads/stores use conditional IR loads/stores
- fix memcheck false-errors regression caused by [2]
- fix gdbserver regression caused by loss of executable stack?
- redo various fixed table sizes for android vs big-64-bit-servers
- try to make OSX108 support work better
- memcheck 16-byte reads (PLO) and other icc false-positive workarounds?
- any further Dwarf4 fixes that we need
- remote debuginfo server support [3]
- fix more bugs:
- the usual bunch of missing ioctls, syscalls, etc
- any critical missing insns (I don't think there are many)
- there are a number of bugs for Helgrind which really should
get looked at
- maybe: AMD perfctr support patches
Most of these are documented in docs/internals/3_8_BUGSTATUS.txt.
To clarify re [3]: having spent quite some time Memchecking large apps
on Android, I really would like for the debuginfo reader to be able to
pull debuginfo from a simple (custom) remote server process, since
pushing more than 1GB of debuginfo objects onto the device each time
is a huge time waster. This will involve inserting an abstraction
layer inside m_debuginfo, so it no longer reads debuginfo directly
from the mmap'd objects. This will likely be a big, intrusive change.
J
|
|
From: Niall D. <ndo...@bl...> - 2013-05-02 15:05:23
Attachments:
smime.p7s
|
> How does that sound? Any counter-proposals? Any other stuff-to-fix? > s390, MIPS and POWER folks, do the proposed dates work for you? I just checked up on the legal state of my patch to callgrind, and absolutely nothing has happened. I'll try to get it to you before end of May, but I'll understand if that's considered too late. The only good thing about the patch is it touches very little of any existing functionality, so code review should be easy with negligible ripples. Niall |
|
From: Rick G. <rcg...@ve...> - 2013-05-02 22:07:02
|
On 5/2/2013 6:18 AM, Julian Seward wrote:
> Greetings.
>
> It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out
> in the next two months or so. I'd like to propose a freeze date of
> Friday 31 May (all new features/fixes should be in by then), and a two
> week stabilisation/test period, ending in release, on Friday 14 June.
>
Any chance of the support for AMD's LWP feature making it in?
https://bugs.kde.org/show_bug.cgi?id=317441
With the patch which is attached to that bug, I am able to run code
which utilizes said instructions through valgrind successfully.
Regards,
Rick
|
|
From: Julian S. <js...@ac...> - 2013-05-03 08:55:08
|
On 05/03/2013 12:06 AM, Rick Gorton wrote: > Any chance of the support for AMD's LWP feature making it in? > https://bugs.kde.org/show_bug.cgi?id=317441 One concern I had was whether this will cause a problem in any way for handling other x86 insn set extensions? Specifically, do the opcodes for LWP overlap/intersect with other existing or proposed extensions that V does not yet handle? J |
|
From: Rick G. <rcg...@ve...> - 2013-05-03 21:19:00
|
On 5/3/2013 4:54 AM, Julian Seward wrote: > On 05/03/2013 12:06 AM, Rick Gorton wrote: >> Any chance of the support for AMD's LWP feature making it in? >> https://bugs.kde.org/show_bug.cgi?id=317441 > One concern I had was whether this will cause a problem in any way > for handling other x86 insn set extensions? Specifically, do the > opcodes for LWP overlap/intersect with other existing or proposed > extensions that V does not yet handle? > > J To the best of my knowledge, not it does not overlap with any others. One part of the patch is to specifically pick up on the fact that the underlying host is truly an AMD system, which would also simplify Intel vs. AMD handling of LZCNT. Regards, Rick |
|
From: Florian K. <br...@ac...> - 2013-05-03 02:00:12
|
For s390 I want the DFP support to be part of the next release. This was a significant undertaking of Maran's and there is a final patch (I believe) in BZ waiting for review. We should be able to nail this before the end of the month. I won't be able to help with testing as I'll be travelling early June. Perhaps IBM folks can lend a hand here. Florian On 05/02/2013 06:18 AM, Julian Seward wrote: > > Greetings. > > It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out > in the next two months or so. I'd like to propose a freeze date of > Friday 31 May (all new features/fixes should be in by then), and a two > week stabilisation/test period, ending in release, on Friday 14 June. > > Considering the stuff still to do (see below), that might be a little > ambitious -- I don't know. > > How does that sound? Any counter-proposals? Any other stuff-to-fix? > s390, MIPS and POWER folks, do the proposed dates work for you? > >>From a quick look through the NEWS file, new stuff since 3.8.0 is: > > - mips64-linux port > - avx2 support > - better control of leak reporting: --show-leak-kinds, > --errors-for-leak-kinds > - better control of block stack traces: --keep-stacktraces > - merge recursive frames in stack unwind: --merge-recursive-frames= > - more GDBserver monitor commands > - greatly improved arm neon load/store performance > - introduction of direct IR support for conditional loads and stores [1] > - use [1] for representing ARM conditional loads/stores [2] > - lots of bugs fixed > - more ppc and zSeries DFP support (?) > > If there's stuff I missed there, please add it to the NEWS file. > > There's still a number of things I'd like to get fixed before release. > > - make avx/avx2 conditional loads/stores use conditional IR loads/stores > - fix memcheck false-errors regression caused by [2] > - fix gdbserver regression caused by loss of executable stack? > - redo various fixed table sizes for android vs big-64-bit-servers > - try to make OSX108 support work better > - memcheck 16-byte reads (PLO) and other icc false-positive workarounds? > - any further Dwarf4 fixes that we need > - remote debuginfo server support [3] > - fix more bugs: > - the usual bunch of missing ioctls, syscalls, etc > - any critical missing insns (I don't think there are many) > - there are a number of bugs for Helgrind which really should > get looked at > - maybe: AMD perfctr support patches > > Most of these are documented in docs/internals/3_8_BUGSTATUS.txt. > > To clarify re [3]: having spent quite some time Memchecking large apps > on Android, I really would like for the debuginfo reader to be able to > pull debuginfo from a simple (custom) remote server process, since > pushing more than 1GB of debuginfo objects onto the device each time > is a huge time waster. This will involve inserting an abstraction > layer inside m_debuginfo, so it no longer reads debuginfo directly > from the mmap'd objects. This will likely be a big, intrusive change. > > J > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Mark W. <mj...@re...> - 2013-05-08 09:47:03
|
On Thu, 2013-05-02 at 12:18 +0200, Julian Seward wrote:
> It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out
> in the next two months or so. I'd like to propose a freeze date of
> Friday 31 May (all new features/fixes should be in by then), and a two
> week stabilisation/test period, ending in release, on Friday 14 June.
That sounds like a good plan.
There are current 40 patches in the fedora valgrind 3.8.1 package [1]
and I would love to get rid of them. I believe they are now all already
in current subversion or at least proposed in bugs. I'll go over them
all again and make sure they really are in before May 31.
I made it so that recent fedora valgrind packages put a summary and all
diff files from failing regtests in the build.log. So it should be easy
to provide an overview of regtests for the architectures supported by
fedora (i686, x86_64, ppc, ppc64, arm7hl and s390x) [2].
If you make pre-release tar balls end of May I can push them to the
fedora rawhide koji builders. And I can probably get the same regtests
overview for RHEL5 and RHEL6 architectures.
> There's still a number of things I'd like to get fixed before release.
> - any further Dwarf4 fixes that we need
Do you have any particular bugs in mind for this?
Thanks,
Mark
[1] Fedora valgrind package source. Look in the fedora.spec file to see
a list of bug numbers corresponding to the patches:
http://pkgs.fedoraproject.org/cgit/valgrind.git/tree/
[2] Fedora koji builders, look in the latest build.log to see an
overview of the regtests at the end:
http://koji.fedoraproject.org/koji/packageinfo?packageID=98
http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=8430
http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=9521
http://s390.koji.fedoraproject.org/koji/packageinfo?packageID=7265
|