|
From: Mark W. <ma...@kl...> - 2021-03-01 13:39:40
|
Hi, We discussed doing a valgrind 3.17.0 release on irc a couple of times, but don't really seem to have a concrete plan. My hope was that we could get everything in before March 1st and then do an RC. But it is March 1 today and I think we aren't really ready yet. So can we make a more concrete plan for 3.17.0? What are the things people believe should go in and which things are just nice to have? What would be a good cut-off date when we can create a release branch/candidate and only fix release blockers/regressions? I tried to go through all the bugs being reported (or changed) since 3.16.1 was released. And I would like to fix the following: - https://bugzilla.redhat.com/show_bug.cgi?id=1923493 netresolve: FTBFS in Fedora rawhide/f34 because valgrind breaks on arm64 - https://bugs.kde.org/show_bug.cgi?id=396656 https://bugs.kde.org/show_bug.cgi?id=427969 Debian/Ubuntu use dwz in an odd way it seems. - https://bugs.kde.org/show_bug.cgi?id=432870 gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64 - https://bugs.kde.org/show_bug.cgi?id=431306 Update demangler to support Rust v0 name mangling Where the last one is just a nice to have. I believe things can be ready for a 3.17.0 release branch/candidate by end of this week, Friday March 5. If people have other bugs they like to really get resolved for 3.17.0 please let me know and I can see how I can help. Cheers, Mark |
|
From: will s. <wil...@vn...> - 2021-03-01 16:24:44
|
On Mon, 2021-03-01 at 14:39 +0100, Mark Wielaard wrote: > Hi, > > We discussed doing a valgrind 3.17.0 release on irc a couple of > times, > but don't really seem to have a concrete plan. My hope was that we > could get everything in before March 1st and then do an RC. > > But it is March 1 today and I think we aren't really ready yet. > > So can we make a more concrete plan for 3.17.0? > > What are the things people believe should go in and which things are > just nice to have? What would be a good cut-off date when we can > create > a release branch/candidate and only fix release blockers/regressions? > > I tried to go through all the bugs being reported (or changed) since > 3.16.1 was released. And I would like to fix the following: > > - https://bugzilla.redhat.com/show_bug.cgi?id=1923493 > netresolve: FTBFS in Fedora rawhide/f34 because valgrind breaks > on arm64 > > - https://bugs.kde.org/show_bug.cgi?id=396656 > https://bugs.kde.org/show_bug.cgi?id=427969 > Debian/Ubuntu use dwz in an odd way it seems. > > - https://bugs.kde.org/show_bug.cgi?id=432870 > gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64 > > - https://bugs.kde.org/show_bug.cgi?id=431306 > Update demangler to support Rust v0 name mangling > > Where the last one is just a nice to have. > > I believe things can be ready for a 3.17.0 release branch/candidate > by > end of this week, Friday March 5. > > If people have other bugs they like to really get resolved for 3.17.0 > please let me know and I can see how I can help. Hi Mark, I would like to see the remainder of the power10 enablement patches make it in. I *think* this is now down to two updated and pending revised review patch sets, 429354 , 429375 The SCV and DARN bugs would ideally be resolved, but they will take as long as they take. There is one additional patch set for power10 support that enables a small number of instructions that we can not yet verify on our early hardware. That patch needs to be posted for review. The window of that one is shrinking,.. Thanks -Will > > Cheers, > > Mark > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:12:38
|
Hi Will, On Mon, 2021-03-01 at 10:01 -0600, will schmidt wrote: > I would like to see the remainder of the power10 enablement patches > make it in. I *think* this is now down to two updated and pending > revised review patch sets, > 429354 , 429375 > > The SCV and DARN bugs would > ideally be resolved, but they will take as long as they take. So they are currently both masked out from HWCAP2 which hopefully signals to applications that they should not use them. I don't believe anybody has tried implementing DARN yet (bug #411189). Maybe it can use the same trick as adm64 RDRAND as implementation? For SCV (bug #431157) testing has been a little tricky since you need the latest glibc, kernel and a power9 setup. I did test Carl's latest patch for SCV support on that, but found it still had some argument/return value passing issues. > There is > one additional patch set for power10 support that enables a small > number of instructions that we can not yet verify on our early > hardware. That patch needs to be posted for review. The window of > that one is shrinking,.. It would be nice to get the power10 patches completed before 3.17.0 is released, but testing that is even harder than the SCV issue. There are also patches waiting for s390x z15, x86_64 avx512 and of course the freebsd support. So if things don't make it for 3.17.0 lets try to do a 3.17.1 or even 3.18.0 release sooner (in 3 or 6 months). Cheers, Mark |
|
From: Carl L. <ce...@us...> - 2021-03-01 17:57:22
|
Mark, Julian: For PPC64, we have the remaining ISA 3.1 instruction support that we would like to get in for the 3.17 release. There are two existing bugzillas for the support. https://bugs.kde.org/show_bug.cgi?id=429354 https://bugs.kde.org/show_bug.cgi?id=429375 The patches in these two bugzillas have been reviewed once by Julian. I have updated the patches in both bugzillas per Julian's comments. I am hopefull the patches will be approved when Julian can review them again. The final set of patches for the ISA 3.1 support were posted today in bugzilla: https://bugs.kde.org/show_bug.cgi?id=433801 These patches are fairly straight forward. I hope we can get them approved fairly quickly so they can be included in the 3.17.0 release. We have an outstanding issue with the scv instruction support, as you know. https://bugs.kde.org/show_bug.cgi?id=431157 Looking at your email and internal discussions, it looks like we need the Linux kernel 5.10.14 and the latest glibc to properly test the patch I created. My testing todate has been on an older kernel using a compiler that I have am now told does not have the scv support. I think this issue will need a lot more time before it is ready to be included in mainline. This fix should not be included in 3.17.0. Additionally, we have noticed a number of helgrind failures in our testing on the latest internal prototype hardware with the latest internal compiler. We are investigating these issues. Currently, they do not appear to be related to the ISA 3.1 support. We will update you on these issues as we dig into them further. Thanks. Carl Love On Mon, 2021-03-01 at 14:39 +0100, Mark Wielaard wrote: > Hi, > > We discussed doing a valgrind 3.17.0 release on irc a couple of > times, > but don't really seem to have a concrete plan. My hope was that we > could get everything in before March 1st and then do an RC. > > But it is March 1 today and I think we aren't really ready yet. > > So can we make a more concrete plan for 3.17.0? > > What are the things people believe should go in and which things are > just nice to have? What would be a good cut-off date when we can > create > a release branch/candidate and only fix release blockers/regressions? > > I tried to go through all the bugs being reported (or changed) since > 3.16.1 was released. And I would like to fix the following: > > - > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1923493&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=D6hL4wfEjz7IOy7eu9P2oeeST2QaXmendCcJCFXs0AE&e= > > netresolve: FTBFS in Fedora rawhide/f34 because valgrind breaks > on arm64 > > - > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.kde.org_show-5Fbug.cgi-3Fid-3D396656&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=BIvrGz7rL1Yklgqvmt9rYswaJ6E7g8IVGgBx8yxVOhE&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.kde.org_show-5Fbug.cgi-3Fid-3D427969&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=RfDoGaOrXtWGB7V9Vl5Sfig4-7luXGG09uyz5kZWmdM&e= > > Debian/Ubuntu use dwz in an odd way it seems. > > - > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.kde.org_show-5Fbug.cgi-3Fid-3D432870&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=mWKhcMBN7HPGbr1gZXV40laMFZDqlJty34zy87JvpVw&e= > > gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64 > > - > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.kde.org_show-5Fbug.cgi-3Fid-3D431306&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=He956C62mh9RbIItPR82QcswHNEGP221hU0h-lYt-WU&e= > > Update demangler to support Rust v0 name mangling > > Where the last one is just a nice to have. > > I believe things can be ready for a 3.17.0 release branch/candidate > by > end of this week, Friday March 5. > > If people have other bugs they like to really get resolved for 3.17.0 > please let me know and I can see how I can help. > > Cheers, > > Mark > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_valgrind-2Ddevelopers&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=RFEmMkZAk--_wFGN5tkM_A&m=htkczODBVgZIXIqrdosIQgJ_rxmXquoMOwpUVQlMc2I&s=0qiyjFjH3fr9ITog5R-mqlMMSYId9Q45YVQC8J0DKI0&e= |
|
From: Paul F. <pj...@wa...> - 2021-03-01 20:37:59
|
On 3/1/21 2:39 PM, Mark Wielaard wrote: > Hi, > > We discussed doing a valgrind 3.17.0 release on irc a couple of times, > but don't really seem to have a concrete plan. My hope was that we > could get everything in before March 1st and then do an RC. Hi Mark I'll push the changes for *Bug 388787* <https://bugs.kde.org/show_bug.cgi?id=388787> - Support for C++17 new/delete tomorrow. A+ Paul |
|
From: Philippe W. <phi...@sk...> - 2021-03-01 20:41:08
|
Hello Mark,
Thanks for the below.
Recently, I had very little time to contribute.
I hope to have a little bit of more time next week, as I am on holiday
(and "thanks" to covid, on holiday at home).
I would like to work on 2 things:
* look at the nlcontrolc test, and change it so that it does not depend
anymore on the modification of the select arguments.
* I would like to do a small change in the way memcheck reports information
about a block.
Currently, a block is described like this:
==21152== Address 0x4a2f100 is 96 bytes inside a block of size 100,000 alloc'd
I would like to change it so that it contains the block address.
I was thinking to the following format:
==18441== Address 0x4a2f100 is 96 bytes inside the block[size] 0x4a2f0a0[100,000] alloc'd
(i.e. uses a format similar to what the monitor command 'block_list' produces.
It is of course possible to calculate the block address from the given address
and the block offset, but this is annoying/time consuming, in particular when you
do a lot of 'who_points_at' under gdb+vgdb to investigate a logical leak.
So, I would like to make this easier by having the address and size of a block.
There are other places where I would like to use the same format e.g. instead of
having who points at telling:
==21496== Searching for pointers pointing in 16 bytes from 0x4a2f3b0
it could rather show:
==21496== Searching for pointers pointing in block[size] 0x4a2f3b0[16]
Feedback welcome before I start to change the block description (and tests) ...
Thanks
Philippe
On Mon, 2021-03-01 at 14:39 +0100, Mark Wielaard wrote:
> Hi,
>
> We discussed doing a valgrind 3.17.0 release on irc a couple of times,
> but don't really seem to have a concrete plan. My hope was that we
> could get everything in before March 1st and then do an RC.
>
> But it is March 1 today and I think we aren't really ready yet.
>
> So can we make a more concrete plan for 3.17.0?
>
> What are the things people believe should go in and which things are
> just nice to have? What would be a good cut-off date when we can create
> a release branch/candidate and only fix release blockers/regressions?
>
> I tried to go through all the bugs being reported (or changed) since
> 3.16.1 was released. And I would like to fix the following:
>
> - https://bugzilla.redhat.com/show_bug.cgi?id=1923493
> netresolve: FTBFS in Fedora rawhide/f34 because valgrind breaks
> on arm64
>
> - https://bugs.kde.org/show_bug.cgi?id=396656
> https://bugs.kde.org/show_bug.cgi?id=427969
> Debian/Ubuntu use dwz in an odd way it seems.
>
> - https://bugs.kde.org/show_bug.cgi?id=432870
> gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64
>
> - https://bugs.kde.org/show_bug.cgi?id=431306
> Update demangler to support Rust v0 name mangling
>
> Where the last one is just a nice to have.
>
> I believe things can be ready for a 3.17.0 release branch/candidate by
> end of this week, Friday March 5.
>
> If people have other bugs they like to really get resolved for 3.17.0
> please let me know and I can see how I can help.
>
> Cheers,
>
> Mark
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:28:57
|
Hi Philippe, On Mon, 2021-03-01 at 21:40 +0100, Philippe Waroquiers wrote: > I would like to work on 2 things: > * look at the nlcontrolc test, and change it so that it does not > depend > anymore on the modification of the select arguments. Yes, this https://bugs.kde.org/show_bug.cgi?id=432870 is a bit of a puzzle. It is also on my list, but I haven't made much progress. I must admit that I don't fully understand how/why it worked before. It seems to rely on valgrind installing signal handlers as SA_RESTART. But even that assumption doesn't really hold since in theory the select call should always return with EINTR instead of being restarted. If you could come up with a testcase that didn't rely on what seems to be magic select behavior that would be great. BTW. See also this arm64 bug report, that is probably the same issue: https://bugs.kde.org/show_bug.cgi?id=338633 > * I would like to do a small change in the way memcheck reports information > about a block. > Currently, a block is described like this: > ==21152== Address 0x4a2f100 is 96 bytes inside a block of size 100,000 alloc'd > > I would like to change it so that it contains the block address. > I was thinking to the following format: > ==18441== Address 0x4a2f100 is 96 bytes inside the block[size] 0x4a2f0a0[100,000] alloc'd > (i.e. uses a format similar to what the monitor command 'block_list' produces. > > It is of course possible to calculate the block address from the given address > and the block offset, but this is annoying/time consuming, in particular when you > do a lot of 'who_points_at' under gdb+vgdb to investigate a logical leak. > > So, I would like to make this easier by having the address and size of a block. > There are other places where I would like to use the same format e.g. instead of > having who points at telling: > ==21496== Searching for pointers pointing in 16 bytes from 0x4a2f3b0 > it could rather show: > ==21496== Searching for pointers pointing in block[size] 0x4a2f3b0[16] > > Feedback welcome before I start to change the block description (and tests) ... Although having the actual block address in the warning message would be really nice I would be a little afraid this would invalidate most/all memcheck testcases unless you can come up with some smart filtering. If we are discussing the color of the bikesed, wording of the warning message then I think I would prefer: Address 0x4a2f100 is 96 bytes inside block 0x4a2f0a0 size 678 Also make sure that the "0 bytes inside" case comes out right/isn't confusing. I think that it might be better to postpone this change to after 3.17.0 is released so we have some time to play with it. Cheers, Mark |
|
From: Carl L. <ce...@us...> - 2021-03-02 19:16:07
|
Mark, Julian:
> Additionally, we have noticed a number of helgrind failures in our
> testing on the latest internal prototype hardware with the latest
> internal compiler. We are investigating these issues. Currently,
> they
> do not appear to be related to the ISA 3.1 support. We will update
> you
> on these issues as we dig into them further.
The issue was the debug info was not installed. Once the debug info
was installed the regression tests run without any helgrind failures.
Carl
|
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:31:59
|
Hi Carl, On Tue, 2021-03-02 at 11:15 -0800, Carl Love wrote: > Additionally, we have noticed a number of helgrind failures in our > > testing on the latest internal prototype hardware with the latest > > internal compiler. We are investigating these issues. Currently, > > they > > do not appear to be related to the ISA 3.1 support. We will update > > you > > on these issues as we dig into them further. > > The issue was the debug info was not installed. Once the debug info > was installed the regression tests run without any helgrind failures. Which components need to have debuginfo installed (valgrind, glibc?) to get this working as intended? If it is valgrind then it is likely a packaging bug (the vgpreload files should not be stripped). If it is glibc then it might be interesting to know whether it relied on the symtab symbols or the full .debug sections. Thanks, Mark |
|
From: Carl L. <ce...@us...> - 2021-03-03 16:32:42
|
Mark:
I was using the IBM AT toolchain. This contains newer glibc, gcc, gdb
etc. then the distro. It is basially more on an internal bleeding edge
release of the tool chain. Initially, the install of the AT toolchain
did not include the debug info. Once I installed the debug info
package the Helgrind packages worked. From what I am told, the debug
info contains all of the debug info for all of the executables. So I
can't really say symtab symbols or the full .debug sections.
Carl
On Wed, 2021-03-03 at 13:31 +0100, Mark Wielaard wrote:
> Hi Carl,
>
> On Tue, 2021-03-02 at 11:15 -0800, Carl Love wrote:
> > Additionally, we have noticed a number of helgrind failures in our
> > > testing on the latest internal prototype hardware with the latest
> > > internal compiler. We are investigating these
> > > issues. Currently,
> > > they
> > > do not appear to be related to the ISA 3.1 support. We will
> > > update
> > > you
> > > on these issues as we dig into them further.
> >
> > The issue was the debug info was not installed. Once the debug
> > info
> > was installed the regression tests run without any helgrind
> > failures.
>
> Which components need to have debuginfo installed (valgrind, glibc?)
> to
> get this working as intended? If it is valgrind then it is likely a
> packaging bug (the vgpreload files should not be stripped). If it is
> glibc then it might be interesting to know whether it relied on the
> symtab symbols or the full .debug sections.
>
> Thanks,
>
> Mark
|