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
|
2
(6) |
3
(1) |
4
(1) |
5
(20) |
6
(3) |
|
7
(1) |
8
(3) |
9
(4) |
10
(1) |
11
(1) |
12
(3) |
13
(5) |
|
14
|
15
|
16
(2) |
17
(3) |
18
(4) |
19
(2) |
20
(1) |
|
21
(1) |
22
(2) |
23
(3) |
24
(2) |
25
(2) |
26
(7) |
27
(1) |
|
28
(28) |
29
|
30
(1) |
|
|
|
|
|
From: <sv...@va...> - 2015-06-17 21:33:26
|
Author: philippe
Date: Wed Jun 17 22:33:19 2015
New Revision: 3153
Log:
A SSE2 only CPU was reported to the guest as a SSE3 CPU.
The guest code might then select functions calling invalid
instructions.
E.G. giving:
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xF
==13094== valgrind: Unrecognised instruction at address 0x496d4d3.
==13094== at 0x496D4D3: __mempcpy_ssse3 (memcpy-ssse3.S:771)
==13094== by 0x125E0B: ??? (in /bin/dash)
as the host hw cap is not SSE3 enabled, while the guest believes
SSE3 can be used.
So, change CPUID so as to report an SSE3 if the hw is SSE3,
and otherwise SSE1 or lower.
(an SSE2 cpu might be added later on)
Modified:
trunk/priv/guest_x86_defs.h
trunk/priv/guest_x86_helpers.c
trunk/priv/guest_x86_toIR.c
Modified: trunk/priv/guest_x86_defs.h
==============================================================================
--- trunk/priv/guest_x86_defs.h (original)
+++ trunk/priv/guest_x86_defs.h Wed Jun 17 22:33:19 2015
@@ -147,7 +147,7 @@
extern void x86g_dirtyhelper_CPUID_sse0 ( VexGuestX86State* );
extern void x86g_dirtyhelper_CPUID_mmxext ( VexGuestX86State* );
extern void x86g_dirtyhelper_CPUID_sse1 ( VexGuestX86State* );
-extern void x86g_dirtyhelper_CPUID_sse2 ( VexGuestX86State* );
+extern void x86g_dirtyhelper_CPUID_sse3 ( VexGuestX86State* );
extern void x86g_dirtyhelper_FINIT ( VexGuestX86State* );
Modified: trunk/priv/guest_x86_helpers.c
==============================================================================
--- trunk/priv/guest_x86_helpers.c (original)
+++ trunk/priv/guest_x86_helpers.c Wed Jun 17 22:33:19 2015
@@ -2324,7 +2324,7 @@
address sizes : 36 bits physical, 48 bits virtual
power management:
*/
-void x86g_dirtyhelper_CPUID_sse2 ( VexGuestX86State* st )
+void x86g_dirtyhelper_CPUID_sse3 ( VexGuestX86State* st )
{
# define SET_ABCD(_a,_b,_c,_d) \
do { st->guest_EAX = (UInt)(_a); \
Modified: trunk/priv/guest_x86_toIR.c
==============================================================================
--- trunk/priv/guest_x86_toIR.c (original)
+++ trunk/priv/guest_x86_toIR.c Wed Jun 17 22:33:19 2015
@@ -14842,9 +14842,9 @@
IRDirty* d = NULL;
void* fAddr = NULL;
const HChar* fName = NULL;
- if (archinfo->hwcaps & VEX_HWCAPS_X86_SSE2) {
- fName = "x86g_dirtyhelper_CPUID_sse2";
- fAddr = &x86g_dirtyhelper_CPUID_sse2;
+ if (archinfo->hwcaps & VEX_HWCAPS_X86_SSE3) {
+ fName = "x86g_dirtyhelper_CPUID_sse3";
+ fAddr = &x86g_dirtyhelper_CPUID_sse3;
}
else
if (archinfo->hwcaps & VEX_HWCAPS_X86_SSE1) {
|
Author: philippe
Date: Wed Jun 17 20:57:09 2015
New Revision: 15341
Log:
324181 mmap does not handle MAP_32BIT (handle it now, rather than fail it)
324181 was previously closed with a solution to always make
MAP_32BIT fail. This is technically correct/according to the doc,
but is not very usable.
This patch ensures that MAP_32BIT mmap is succesful, as long as
aspacemgr gives a range in the first 2GB
(so, compared to a native run, MAP_32BIT will fail much more quickly
as aspacemgr does not reserve the address space below 2GB on a 64 bits).
Far to be perfect, but this is better than nothing.
Added a regression test that test succesful mmap 32 bits till
the 2GB limit is reached.
Added:
trunk/none/tests/amd64-linux/map_32bits.c
trunk/none/tests/amd64-linux/map_32bits.stderr.exp
trunk/none/tests/amd64-linux/map_32bits.vgtest
Modified:
trunk/NEWS
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/none/tests/amd64-linux/Makefile.am
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Wed Jun 17 20:57:09 2015
@@ -115,6 +115,7 @@
'sizeof(UWord) == sizeof(UInt)' failed in m_syscall.c
== 326797
319274 Fix unhandled syscall: unix:410 (sigsuspend_nocancel) on OS X
+324181 mmap does not handle MAP_32BIT (handle it now, rather than fail it)
333051 mmap of huge pages fails due to incorrect alignment
== 339163
334802 valgrind does not always explain why a given option is bad
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
==============================================================================
--- trunk/coregrind/m_syswrap/syswrap-generic.c (original)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c Wed Jun 17 20:57:09 2015
@@ -2150,15 +2150,6 @@
return VG_(mk_SysRes_Error)( VKI_EINVAL );
}
-# if defined(VKI_MAP_32BIT)
- /* We can't support MAP_32BIT (at least, not without significant
- complication), and it's royally unportable, so if the client
- asks for it, just fail it. */
- if (arg4 & VKI_MAP_32BIT) {
- return VG_(mk_SysRes_Error)( VKI_ENOMEM );
- }
-# endif
-
/* Figure out what kind of allocation constraints there are
(fixed/hint/any), and ask aspacem what we should do. */
mreq.start = arg1;
@@ -2179,12 +2170,37 @@
return VG_(mk_SysRes_Error)( VKI_EINVAL );
}
+# if defined(VKI_MAP_32BIT)
+ /* MAP_32BIT is royally unportable, so if the client asks for it, try our
+ best to make it work (but without complexifying aspacemgr).
+ If the user requested MAP_32BIT, the mmap-ed space must be in the
+ first 2GB of the address space. So, return ENOMEM if aspacemgr
+ advisory is above the first 2GB. If MAP_FIXED is also requested,
+ MAP_32BIT has to be ignored.
+ Assumption about aspacemgr behaviour: aspacemgr scans the address space
+ from low addresses to find a free segment. No special effort is done
+ to keep the first 2GB 'free' for this MAP_32BIT. So, this will often
+ fail once the program has already allocated significant memory. */
+ if ((arg4 & VKI_MAP_32BIT) && !(arg4 & VKI_MAP_FIXED)) {
+ if (advised + arg2 >= 0x80000000)
+ return VG_(mk_SysRes_Error)( VKI_ENOMEM );
+ }
+# endif
+
/* Otherwise we're OK (so far). Install aspacem's choice of
address, and let the mmap go through. */
sres = VG_(am_do_mmap_NO_NOTIFY)(advised, arg2, arg3,
arg4 | VKI_MAP_FIXED,
arg5, arg6);
+# if defined(VKI_MAP_32BIT)
+ /* No recovery trial if the advisory was not accepted. */
+ if ((arg4 & VKI_MAP_32BIT) && !(arg4 & VKI_MAP_FIXED)
+ && sr_isError(sres)) {
+ return VG_(mk_SysRes_Error)( VKI_ENOMEM );
+ }
+# endif
+
/* A refinement: it may be that the kernel refused aspacem's choice
of address. If we were originally asked for a hinted mapping,
there is still a last chance: try again at any address.
Modified: trunk/none/tests/amd64-linux/Makefile.am
==============================================================================
--- trunk/none/tests/amd64-linux/Makefile.am (original)
+++ trunk/none/tests/amd64-linux/Makefile.am Wed Jun 17 20:57:09 2015
@@ -5,10 +5,11 @@
filter_stderr filter_minimal
EXTRA_DIST = \
- bug345887.stderr.exp bug345887.vgtest
+ bug345887.stderr.exp bug345887.vgtest \
+ map_32bits.stderr.exp map_32bits.vgtest
check_PROGRAMS = \
- bug345887
+ bug345887 map_32bits
AM_CFLAGS += @FLAG_M64@
AM_CXXFLAGS += @FLAG_M64@
Added: trunk/none/tests/amd64-linux/map_32bits.c
==============================================================================
--- trunk/none/tests/amd64-linux/map_32bits.c (added)
+++ trunk/none/tests/amd64-linux/map_32bits.c Wed Jun 17 20:57:09 2015
@@ -0,0 +1,43 @@
+#include <stdio.h>
+#include "tests/sys_mman.h"
+#include <stdlib.h>
+#include <unistd.h>
+
+int main()
+{
+
+ void *first = NULL;
+ void *last;
+ void *res;
+
+ while (1) {
+ res = mmap (NULL, 64 * 1024,
+ PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT,
+ -1, 0);
+ if (first == NULL) {
+ first = res;
+ if (first == (void *)-1) {
+ perror ("first mmap");
+ exit (1);
+ }
+ fprintf(stderr, "first mmap : %p\n", first);
+ }
+ if (res == (void *)-1) {
+ fprintf(stderr, "last mmap ok: %p\n", last);
+ break;
+ }
+ last = res;
+ }
+
+ /* And now, retry without MAP_32BIT */
+ res = mmap (NULL, 64 * 1024,
+ PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
+ -1, 0);
+ if (res == (void *)-1) {
+ perror ("retry mmap");
+ exit (1);
+ }
+ fprintf(stderr, "retry mmap ok: %p\n", res);
+
+ return 0;
+}
Added: trunk/none/tests/amd64-linux/map_32bits.stderr.exp
==============================================================================
--- trunk/none/tests/amd64-linux/map_32bits.stderr.exp (added)
+++ trunk/none/tests/amd64-linux/map_32bits.stderr.exp Wed Jun 17 20:57:09 2015
@@ -0,0 +1,3 @@
+first mmap : 0x........
+last mmap ok: 0x........
+retry mmap ok: 0x........
Added: trunk/none/tests/amd64-linux/map_32bits.vgtest
==============================================================================
--- trunk/none/tests/amd64-linux/map_32bits.vgtest (added)
+++ trunk/none/tests/amd64-linux/map_32bits.vgtest Wed Jun 17 20:57:09 2015
@@ -0,0 +1,5 @@
+prog: map_32bits
+# take a big aspacemgr minaddr, to quickly reach the 2GB limit
+vgopts: -q --aspace-minaddr=0x7ff60000
+stderr_filter: filter_minimal
+
|
|
From: Matthias S. <zz...@ge...> - 2015-06-17 19:43:46
|
On 05.06.2015 15:33, sv...@va... wrote: > Author: sewardj > Date: Fri Jun 5 14:33:46 2015 > New Revision: 15317 > > Log: > arm32-linux only: add handwritten assembly helpers for > MC_(helperc_LOADV32le), MC_(helperc_LOADV16le) and > MC_(helperc_LOADV8). This improves performance by around 5% to 7% in > the best case, for run-of-the-mill integer code. > > Hi! I tried this for x86. I am not yet 100% sure if the code is now the fastest possible way. * Alignment of function and of jump targets? necessary at all? * Should the byte result from the secmap be stored in %dl or extended to 32bits and be in %edx? * Should the asm functions be defined in a .s file? Then the debug info can also point to the file and line number. But the ifdef-ing will be harder. I tried to compare: 1. valgrind-trunk compiled with gcc-4.8.4 2. valgrind-trunk compiled with gcc-4.9.2 3. my modified valgrind-trunk compiled with gcc-4.9.2 The results are mixed. code from gcc-4.8.4 was faster than gcc-4.9.2. and hand-optimized code was sometimes faster than gcc-4.8.4. Maybe I should compile hand-optimized version also with gcc-4.8.4. Which test (of the perf suite or something else) should I use. I did run the perf suite hosted in callgrind. The numbers for tinycc test are attached. In this case helperc_LOADV32le seems to be more than 13% faster than the gcc-4.9.2 version. and it might be the same speed as gcc-4.8.4 version, but I don't know exactly how to understand the created numbers. Will "perf stat" applied to normal vg-in-place give better results? At least it runs a lot faster. Regards Matthias |