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
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(1) |
2
|
|
3
(5) |
4
(7) |
5
(16) |
6
(7) |
7
(5) |
8
|
9
|
|
10
(3) |
11
(7) |
12
(7) |
13
(15) |
14
(4) |
15
(8) |
16
(10) |
|
17
(1) |
18
(7) |
19
(5) |
20
(17) |
21
(10) |
22
(5) |
23
|
|
24
|
25
|
26
(10) |
27
(21) |
28
(18) |
29
(7) |
30
(4) |
|
From: Josef W. <Jos...@gm...> - 2011-04-20 21:18:28
|
On Wednesday 20 April 2011, sv...@va... wrote: > Author: sewardj > Date: 2011-04-20 12:54:32 +0100 (Wed, 20 Apr 2011) > New Revision: 11704 > > Log: > Change a bunch of < > style includes to " " style. Oops. Thanks. That is a relict from the old times when callgrind was standalone, using installed valgrind headers. Josef |
|
From: Christian B. <bor...@de...> - 2011-04-20 20:38:08
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z10 (s390x) ) Started at 2011-04-20 22:10:01 CEST Ended at 2011-04-20 22:37:53 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 460 tests, 6 stderr failures, 0 stdout failures, 0 post failures == none/tests/faultstatus (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-04-20 20:28:52
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-04-20 22:10:01 CEST Ended at 2011-04-20 22:27:58 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 459 tests, 6 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Philippe W. <phi...@sk...> - 2011-04-20 20:12:10
|
I also support the statement that line numbers are often not precise enough. If there is a user demand for this (at work, nobody ever complained), then this should for sure not be hardcoded, i.e. this should be the addition of a command line option to disable showing the program counter. > On 04/20/2011 07:21 AM, Alexander Potapenko wrote: >> Spending much time on debugging the reports from the TSan tool I would >> suggest not to remove the addresses. >> You don't need those while you have the debug info, > > In practice, line numbers are not precise enough. The same line often > maps to many different and non-consecutive PCs, and consecutive PCs > often map to non-consecutive lines. Debugging often involves mental > "backward execution". Not having the correct PC as a starting point > makes it much harder than necessary. |
|
From: Konstantin S. <kon...@gm...> - 2011-04-20 18:15:47
|
> > > * Support for Android? [bug 266035] There appear to be increasing > requests for this. I have no idea of the state of the patchset on > 266035. If it works well and is low-ish risk then maybe it should > be integrated for 3.7.0. If you care about Android support, please > try this out and give feedback. > > Evgeniy will update the bug very soon. He can run a hacked Memcheck and TSan on Android, but that's not as smooth as on x86/Linux yet :) --kcc |
|
From: Konstantin S. <kon...@gm...> - 2011-04-20 18:13:17
|
I would implement an option to enable/disable addresses (--show-pc=no/yes). As for the default value -- I don't know. (TSan's default is no, but I myself suffer from it periodically). --kcc On Wed, Apr 20, 2011 at 6:21 PM, Alexander Potapenko <gl...@go...>wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B > > > Alex > > On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote: > > On 20/04/11 11:12, Julian Seward wrote: > > > >> * change of backtrace format? For years we've had code addresses > >> in backtraces. They use up valuable screen space, but 99% of the > >> time are completely useless. Should we omit them by default, > >> as does the TSan tool? > >> eg > >> Invalid write of size 1 > >> at 0x400544: ddd (errs1.c:7) > >> by 0x400550: ccc (errs1.c:8) > >> by 0x40055B: bbb (errs1.c:9) > >> by 0x400566: aaa (errs1.c:10) > >> by 0x4005AE: main (errs1.c:17) > >> vs > >> Invalid write of size 1 > >> #0 ddd (errs1.c:7) > >> #1 ccc (errs1.c:8) > >> #2 bbb (errs1.c:9) > >> #3 aaa (errs1.c:10) > >> #4 main (errs1.c:17) > > > > I agree that the address is generally not useful, except I would say in > > the case of the first frame, where it gives you the address of the exact > > instruction which triggered the report. > > > > Maybe we could capture that on the first line, something like: > > > > Invalid write of size 1 at 0x400544 > > > > and then drop the addresses from the stack trace. > > > > Tom > > > > -- > > Tom Hughes (to...@co...) > > http://compton.nu/ > > > > > ------------------------------------------------------------------------------ > > Benefiting from Server Virtualization: Beyond Initial Workload > > Consolidation -- Increasing the use of server virtualization is a top > > priority.Virtualization can reduce costs, simplify management, and > improve > > application availability and disaster protection. Learn more about > boosting > > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > -- > Alexander Potapenko > Software Engineer > Google Moscow > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Michael S. <ms...@ap...> - 2011-04-20 15:53:04
|
Or only show the address when line number information is not available? On Apr 20, 2011, at 7:21 AM, Alexander Potapenko wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B > > > Alex > > On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote: >> On 20/04/11 11:12, Julian Seward wrote: >> >>> * change of backtrace format? For years we've had code addresses >>> in backtraces. They use up valuable screen space, but 99% of the >>> time are completely useless. Should we omit them by default, >>> as does the TSan tool? >>> eg >>> Invalid write of size 1 >>> at 0x400544: ddd (errs1.c:7) >>> by 0x400550: ccc (errs1.c:8) >>> by 0x40055B: bbb (errs1.c:9) >>> by 0x400566: aaa (errs1.c:10) >>> by 0x4005AE: main (errs1.c:17) >>> vs >>> Invalid write of size 1 >>> #0 ddd (errs1.c:7) >>> #1 ccc (errs1.c:8) >>> #2 bbb (errs1.c:9) >>> #3 aaa (errs1.c:10) >>> #4 main (errs1.c:17) >> >> I agree that the address is generally not useful, except I would say in >> the case of the first frame, where it gives you the address of the exact >> instruction which triggered the report. >> >> Maybe we could capture that on the first line, something like: >> >> Invalid write of size 1 at 0x400544 >> >> and then drop the addresses from the stack trace. >> >> Tom >> >> -- >> Tom Hughes (to...@co...) >> http://compton.nu/ >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > > > -- > Alexander Potapenko > Software Engineer > Google Moscow > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers __________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair |
|
From: John R. <jr...@bi...> - 2011-04-20 15:00:45
|
On 04/20/2011 07:21 AM, Alexander Potapenko wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, In practice, line numbers are not precise enough. The same line often maps to many different and non-consecutive PCs, and consecutive PCs often map to non-consecutive lines. Debugging often involves mental "backward execution". Not having the correct PC as a starting point makes it much harder than necessary. but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B Fields that have an almost-fixed width should have a preference for the fixed side [the left side] of a line, so that columnar organization tends to be evident and usable. The width of the PC is nearly fixed, while the width of the source designator is much more variable. The above example, with only one filename, and with line numbers having the same floor(log10(__LINE__)), is not typical. -- |
|
From: John R. <jr...@bi...> - 2011-04-20 14:41:18
|
> It's time to think a bit about a 3.7.0 release. [snip] > Other stuff that I forgot / missed? https://bugs.kde.org/show_bug.cgi?id=250101 [contains patch] huge "free" memory usage due to m_mallocfree.c "superblocks fragmentation" Quadratic behavior should not be tolerated. -- |
|
From: Alexander P. <gl...@go...> - 2011-04-20 14:21:27
|
Spending much time on debugging the reports from the TSan tool I would
suggest not to remove the addresses.
You don't need those while you have the debug info, but if you don't,
you'll have to re-run the program with the --show-pc=yes option in
order to debug a newly appeared report (the old and known ones are
already suppressed, aren't they?).
Maybe just move the address to the end of line? Like this:
Invalid write of size 1
at ddd (errs1.c:7), pc=0x400544
by ccc (errs1.c:8), pc=0x400550
by bbb (errs1.c:9), pc=0x40055B
Alex
On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote:
> On 20/04/11 11:12, Julian Seward wrote:
>
>> * change of backtrace format? For years we've had code addresses
>> in backtraces. They use up valuable screen space, but 99% of the
>> time are completely useless. Should we omit them by default,
>> as does the TSan tool?
>> eg
>> Invalid write of size 1
>> at 0x400544: ddd (errs1.c:7)
>> by 0x400550: ccc (errs1.c:8)
>> by 0x40055B: bbb (errs1.c:9)
>> by 0x400566: aaa (errs1.c:10)
>> by 0x4005AE: main (errs1.c:17)
>> vs
>> Invalid write of size 1
>> #0 ddd (errs1.c:7)
>> #1 ccc (errs1.c:8)
>> #2 bbb (errs1.c:9)
>> #3 aaa (errs1.c:10)
>> #4 main (errs1.c:17)
>
> I agree that the address is generally not useful, except I would say in
> the case of the first frame, where it gives you the address of the exact
> instruction which triggered the report.
>
> Maybe we could capture that on the first line, something like:
>
> Invalid write of size 1 at 0x400544
>
> and then drop the addresses from the stack trace.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
--
Alexander Potapenko
Software Engineer
Google Moscow
|
|
From: <sv...@va...> - 2011-04-20 11:54:41
|
Author: sewardj Date: 2011-04-20 12:54:32 +0100 (Wed, 20 Apr 2011) New Revision: 11704 Log: Change a bunch of < > style includes to " " style. Modified: trunk/callgrind/bbcc.c trunk/callgrind/command.c trunk/callgrind/costs.c trunk/callgrind/dump.c trunk/callgrind/main.c trunk/callgrind/threads.c Modified: trunk/callgrind/bbcc.c =================================================================== --- trunk/callgrind/bbcc.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/bbcc.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -29,7 +29,7 @@ #include "global.h" #include "costs.h" -#include <pub_tool_threadstate.h> +#include "pub_tool_threadstate.h" /*------------------------------------------------------------*/ /*--- BBCC operations ---*/ Modified: trunk/callgrind/command.c =================================================================== --- trunk/callgrind/command.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/command.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -32,7 +32,7 @@ #include "config.h" #include "global.h" -#include <pub_tool_threadstate.h> // VG_N_THREADS +#include "pub_tool_threadstate.h" // VG_N_THREADS // Version for the syntax in command/result files for interactive control #define COMMAND_VERSION "1.0" Modified: trunk/callgrind/costs.c =================================================================== --- trunk/callgrind/costs.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/costs.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -28,7 +28,7 @@ #include "global.h" -#include <pub_tool_mallocfree.h> +#include "pub_tool_mallocfree.h" #define COSTCHUNK_SIZE 100000 Modified: trunk/callgrind/dump.c =================================================================== --- trunk/callgrind/dump.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/dump.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -29,8 +29,8 @@ #include "config.h" #include "global.h" -#include <pub_tool_threadstate.h> -#include <pub_tool_libcfile.h> +#include "pub_tool_threadstate.h" +#include "pub_tool_libcfile.h" /* Dump Part Counter */ Modified: trunk/callgrind/main.c =================================================================== --- trunk/callgrind/main.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/main.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -35,7 +35,7 @@ #include "callgrind.h" #include "global.h" -#include <pub_tool_threadstate.h> +#include "pub_tool_threadstate.h" #include "cg_branchpred.c" Modified: trunk/callgrind/threads.c =================================================================== --- trunk/callgrind/threads.c 2011-04-18 11:26:25 UTC (rev 11703) +++ trunk/callgrind/threads.c 2011-04-20 11:54:32 UTC (rev 11704) @@ -28,7 +28,7 @@ #include "global.h" -#include <pub_tool_threadstate.h> +#include "pub_tool_threadstate.h" /* forward decls */ static exec_state* exec_state_save(void); |
|
From: Julian S. <js...@ac...> - 2011-04-20 11:46:20
|
> These instructions have a startup cost, so just doing 8 or > 16 bytes at a time is slower but it probably should work > reasonably enough. Yeah. This is kind of similar to the way CRC32 works on amd64. > Then I have to find a good way to let a clean > helper return a 128 bit value. I don't know of any good way using the existing IR infrastructure. One bad way I have used in the past (try not to die laughing) is to call the helper twice, passing it a bool that indicates whether it should return the lower or upper 64 bits of the result. Yes, it's brain-dead-moron stuff. But yes, it works. See amd64g_calculate_RCR(). In fact it is very annoying not to be able to pass 128 bit values to/from clean helpers -- it has caused a lot of extra complexity in the SSEx implementations. And in future for AVX I suspect I will want to pass 256 bit vectors to/from helpers. It would be good perhaps to contemplate how to extend the clean helper IR stuff just a little bit, so it is possible to pass 128 values in/out by reference. Maybe the cleanest solution is to allow args and/or result type to be Ity_V128, and put the burden on the instruction selectors, so that when they see such an arg type or result type, they generate code to allocate space on the (host) stack, and pass the address of that instead to the helper. Of course this means we'd also have to document that a helper function expecting to deal with such arguments must pass/return them by reference. IOW specify how to write such a function in a way that is compatible with the proposed instruction selector changes. > The message digest functions (e.g. SHA512) will be a little more > tricky, since they have up to 128byte as data block size. Here > we might need a dirty helper instead of a clean one. And I still > dont know how to pass back 512bits without going over memory. I have no suggestions for that. J |
|
From: Tom H. <to...@co...> - 2011-04-20 11:17:30
|
On 20/04/11 11:12, Julian Seward wrote: > * change of backtrace format? For years we've had code addresses > in backtraces. They use up valuable screen space, but 99% of the > time are completely useless. Should we omit them by default, > as does the TSan tool? > eg > Invalid write of size 1 > at 0x400544: ddd (errs1.c:7) > by 0x400550: ccc (errs1.c:8) > by 0x40055B: bbb (errs1.c:9) > by 0x400566: aaa (errs1.c:10) > by 0x4005AE: main (errs1.c:17) > vs > Invalid write of size 1 > #0 ddd (errs1.c:7) > #1 ccc (errs1.c:8) > #2 bbb (errs1.c:9) > #3 aaa (errs1.c:10) > #4 main (errs1.c:17) I agree that the address is generally not useful, except I would say in the case of the first frame, where it gives you the address of the exact instruction which triggered the report. Maybe we could capture that on the first line, something like: Invalid write of size 1 at 0x400544 and then drop the addresses from the stack trace. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Christian B. <bor...@de...> - 2011-04-20 11:01:04
|
Am 20.04.2011 11:24, schrieb Julian Seward: > Can you explain more about the instruction(s)? What exactly are the > inputs and the outputs? I am wondering if this can be done somehow > using clean helpers. One example is the KM (Cipher Message) instruction: KM R1,R2 Register 0 contains the function code(e.g. KM-AES-256) Register 1 contains the parameter block (e.g. the key) Register R1 contains the address of the target Register R2 contains the address of the source Register R2+1 contains the length of the source Your comment about clean helper made me rethink and I was rereading that stuff again. The encryption functions seem to be ok. It seems that the length must be a multiple of the basic data block size (e.g. 16 for AES) and for the ones I checked, the output is really calculated blockwise. (the chaining value is updated in the parameter block). These instructions have a startup cost, so just doing 8 or 16 bytes at a time is slower but it probably should work reasonably enough. Then I have to find a good way to let a clean helper return a 128 bit value. The message digest functions (e.g. SHA512) will be a little more tricky, since they have up to 128byte as data block size. Here we might need a dirty helper instead of a clean one. And I still dont know how to pass back 512bits without going over memory. Christian For reference the instructions KM, KMC, KLMD, KMAC etc. are in http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf |
|
From: Julian S. <js...@ac...> - 2011-04-20 10:13:13
|
Greetings.
It's time to think a bit about a 3.7.0 release. The following are
proposals, for contemplation/discussion.
I'd propose a release at end July or some time in August. That would
put it approximately 10 months after 3.6.0. In the past the gap
between releases has become IMO too long, so I'd like to ship 3.7.0
sooner rather than leave it late in the year.
Pretty definite to go in is:
* support for Fedora 15, Ubuntu 11.04, gcc 4.6, LLVM 2.9 [bug 242137,
unresolved, apparently line numbers don't work], Xcode 4.0.x [bug
267997, complete, but needs more testing]. General help in
testing/verifying these is required -- there's no way I can properly
test all this stuff myself.
* s390x port [bug 243404, completed, misc tidyup patches in progress]
* initial support for Power7 instructions [bug 267630, in progress]
* merge the HGDEV2 branch -- scalability and feature improvements for
Helgrind [no bug number]
* gdbserver integration [bug 214909, in progress]
* remove the AIX port. It has not been buildable since 3.4.1 and is
badly bit-rotted
* reduce the scope of exp-ptrcheck by removing the heap checks,
leaving just the stack and global array checking. The heap checking
was expensive, sometimes had a high false positive level, and
Memcheck does a better job 99%+ of the time. But the stack and
global checks are marginally useful. As a result, rename it to
"exp-sgcheck" ("sg" == stack and global)
More speculative:
* Alon Zakai's massdiff (Massif heap-snapshot differencing) patch [bug
269067]. I'd like this to be included, in some form -- the ability
to difference heap snapshots is very useful.
* Support for Android? [bug 266035] There appear to be increasing
requests for this. I have no idea of the state of the patchset on
266035. If it works well and is low-ish risk then maybe it should
be integrated for 3.7.0. If you care about Android support, please
try this out and give feedback.
* AVX (256-bit vector instructions) support for x86_64. AVX is a
massive bundle of stuff, and getting this completed in the next
three months strikes me as close to impossible. It might be
possible to get the basic infrastructure in place, though (VEX
prefix decoding, basic 256-bit vector stuff in IR and in the x86_64
backend, etc).
It also seems fairly low priority to me. AFAICS we have no bug
reports about non-support of AVX so far. Even the uptake of SSE4.x
was surprisingly slow.
* change of backtrace format? For years we've had code addresses
in backtraces. They use up valuable screen space, but 99% of the
time are completely useless. Should we omit them by default,
as does the TSan tool?
eg
Invalid write of size 1
at 0x400544: ddd (errs1.c:7)
by 0x400550: ccc (errs1.c:8)
by 0x40055B: bbb (errs1.c:9)
by 0x400566: aaa (errs1.c:10)
by 0x4005AE: main (errs1.c:17)
vs
Invalid write of size 1
#0 ddd (errs1.c:7)
#1 ccc (errs1.c:8)
#2 bbb (errs1.c:9)
#3 aaa (errs1.c:10)
#4 main (errs1.c:17)
Other stuff that I forgot / missed?
|
|
From: Julian S. <js...@ac...> - 2011-04-20 09:25:34
|
> Since crypto cannot be modeled in an efficient way we first > thought that a dirty helper might be the right solution, but there are > some problems: > - Dirty can only have one memory area > - The length field (mSize) cannot be an IRTemp > > What might be a good approach to tackle these instruction? Can we enhance > Dirty helpers to accept multiple memory areas with dynamic length fields > (this would require changes in most tools, I guess)? This would be particularly complicated for Memcheck. See do_shadow_Dirty and do_origins_Dirty in mc_translate.c for the current handling. It's not pretty. Can you explain more about the instruction(s)? What exactly are the inputs and the outputs? I am wondering if this can be done somehow using clean helpers. J |
|
From: Christian B. <bor...@de...> - 2011-04-20 08:54:50
|
Folks, Currently Divya is doing some more work on missing instructions for s390x (e.g. stck, translate etc.). I will open bugzillas for these when the patches are ready. There are some crypto instructions (hashing, DES, etc.) which we also want to implement. These instruction get a parameter block two memory fields and a length. Since crypto cannot be modeled in an efficient way we first thought that a dirty helper might be the right solution, but there are some problems: - Dirty can only have one memory area - The length field (mSize) cannot be an IRTemp What might be a good approach to tackle these instruction? Can we enhance Dirty helpers to accept multiple memory areas with dynamic length fields (this would require changes in most tools, I guess)? Any better ideas? Christian |