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
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Tom H. <to...@co...> - 2005-03-30 09:36:05
|
In message <424...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Tom Hughes wrote:
>
>>Does anybody have any suggestions for a better way to make the code
>>in dispatch.S position independent?
>
> You could just use globals and make position-independent references to
> them. Look at the gcc -S output to see what the syntax is; I have a
> patch somewhere which does this, but I can't find it right now.
Like the attached patch you mean? That still adds loads to the
fast path because you have to load the address from the GOT before
you can use it.
This patch actually adds four loads. One can be eliminate by looking
up instr_ptr_offset once at the start and caching it on the stack. The
dispatch_ctr one could probably be eliminate by keeping a local copy
of the dispatch counter and updating the global at the end.
The tt_fast and tt_fastN ones are a problem however as you don't seem
to be able to do this:
movq VG_(tt_fast)@GOTPCREL(%rip,%rbx,8), %rcx
so you have to do this:
movq VG_(tt_fast)@GOTPCREL(%rip), %rcx
movq (%rcx,%rbx,8), %rcx
and the same for the tt_fastN array.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-30 08:50:44
|
Nicholas Nethercote wrote:
> I attach a revised version of my patch, which has a small improvement
> in the way that the size of redzones in the client arena is handled --
> the size is now specified as an argument to VG_(malloc_funcs) rather
> than in the VG_DETERMINE_INTERFACE_VERSION macro, which is much better.
Yes, that's good.
> Otherwise, it's unchanged. What do you both think about the way tool
> functions are registered, given the discussion we've had about the
> constraints involved? As I said before, if I committed this it would
> only be the first step of several. Or, I could do more changes and
> submit a larger patch, so you could see what things would look like
> further along that road. Let me know what you both think.
Even assuming the "all-or-none" condition is really invarient for all
these VG_(*_funcs)() functions, which I'm unconvinced about, I think
functions with lots of arguments are inherently unreadable and hard to
maintain. I'd really prefer to go with structures of pointers to
functions: at least you can name the fields and order isn't important.
(At the very very least, the redzone arg to VG_(malloc_funcs)() should
be first, so that new allocators can be added without having to move it,
or embed it in the middle of unrelated arguments.)
J
|
|
From: Tom H. <to...@co...> - 2005-03-30 08:48:41
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 29 Mar 2005, Julian Seward wrote:
>
>> What I want to happen is for a Kernel-services Abstraction Layer
>> (Kal) to appear. In the same way that Moz has NPSR, OOo has
>> SAL, etc. Kal will provide services like mmap etc whilst hiding
>> the details of how the call is done on different platforms. Of
>> course Kal will be far simpler than NPSR, SAL, etc, but the idea
>> is the same.
>>
>> So that's something worth looking into. I plan to do this myself
>> anyway at some stage, but if you want to look into it, please do.
>
> Tom, perhaps you could generate some patches and post them to the list
> to see how they turn out. It will be interesting to see how much libc
> stuff is platform-specific.
Attached is a first cut at a kernel abstraction layer. It removes
most of the direct system calls from the coregrind directory and
moves them into KAL routines. As a side effect it implements the
missing mylibc functionality for amd64.
I've made a start on removing VKI types from the KAL interface as
any abstraction layer will need to be independent of the types used
to communicate with the kernel. Many routines still use VKI types
in their interface however.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 05:05:44
|
On Mon, 28 Mar 2005, Julian Seward wrote: > Simplifying the tool interface is definitely a Good Thing To Do. However > I'm not convinced by the objections raised thus far to the struct passing > approach, and I like its simplicity. Reasons below. Jeremy, Julian, I attach a revised version of my patch, which has a small improvement in the way that the size of redzones in the client arena is handled -- the size is now specified as an argument to VG_(malloc_funcs) rather than in the VG_DETERMINE_INTERFACE_VERSION macro, which is much better. Otherwise, it's unchanged. What do you both think about the way tool functions are registered, given the discussion we've had about the constraints involved? As I said before, if I committed this it would only be the first step of several. Or, I could do more changes and submit a larger patch, so you could see what things would look like further along that road. Let me know what you both think. N |
|
From: Tom H. <to...@co...> - 2005-03-30 02:28:37
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-30 03:20:05 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 23659 Segmentation fault VALGRINDLIB=/tmp/valgrind.30973/valgrind/.in_place /tmp/valgrind.30973/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 207 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:22:18
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-30 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 206 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:16:25
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-30 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 3 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:15:23
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-30 03:00:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:11:51
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-30 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 205 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/distinguished-writes (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 00:29:18
|
On Tue, 29 Mar 2005, Julian Seward wrote: > What I want to happen is for a Kernel-services Abstraction Layer > (Kal) to appear. In the same way that Moz has NPSR, OOo has > SAL, etc. Kal will provide services like mmap etc whilst hiding > the details of how the call is done on different platforms. Of > course Kal will be far simpler than NPSR, SAL, etc, but the idea > is the same. > > So that's something worth looking into. I plan to do this myself > anyway at some stage, but if you want to look into it, please do. Tom, perhaps you could generate some patches and post them to the list to see how they turn out. It will be interesting to see how much libc stuff is platform-specific. N |
|
From: <sv...@va...> - 2005-03-29 21:35:12
|
Author: sewardj
Date: 2005-03-29 22:35:08 +0100 (Tue, 29 Mar 2005)
New Revision: 1111
Modified:
trunk/pub/libvex_basictypes.h
trunk/switchback/linker.c
trunk/switchback/switchback.c
Log:
Use cpp symbol __x86_64__ rather than __amd64__ on the advice of
Michael Matz.
Modified: trunk/pub/libvex_basictypes.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/pub/libvex_basictypes.h 2005-03-29 21:33:11 UTC (rev 1110)
+++ trunk/pub/libvex_basictypes.h 2005-03-29 21:35:08 UTC (rev 1111)
@@ -124,7 +124,7 @@
=20
#undef VEX_HOST_WORDSIZE
=20
-#if defined(__amd64__)
+#if defined(__x86_64__)
# define VEX_HOST_WORDSIZE 8
#elif defined(__i386__)
# define VEX_HOST_WORDSIZE 4
Modified: trunk/switchback/linker.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/switchback/linker.c 2005-03-29 21:33:11 UTC (rev 1110)
+++ trunk/switchback/linker.c 2005-03-29 21:35:08 UTC (rev 1111)
@@ -18,7 +18,7 @@
static int debug_linker =3D 0;
=20
=20
-#if defined(__amd64__)
+#if defined(__x86_64__)
# define x86_64_TARGET_ARCH
#elif defined(__i386__)
# define i386_TARGET_ARCH
@@ -1175,7 +1175,7 @@
=20
if (secno =3D=3D SHN_COMMON) {
isLocal =3D FALSE;
-# if defined(__amd64__)
+# if defined(__x86_64__)
ad =3D calloc_below2G(1, stab[j].st_size);
# else
ad =3D calloc(1, stab[j].st_size);
Modified: trunk/switchback/switchback.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/switchback/switchback.c 2005-03-29 21:33:11 UTC (rev 1110)
+++ trunk/switchback/switchback.c 2005-03-29 21:35:08 UTC (rev 1111)
@@ -35,7 +35,7 @@
# define VexArch VexArchX86
# define VexSubArch VexSubArchX86_sse1
# define GuestPC guest_EIP
-#elif defined(__amd64__)
+#elif defined(__x86_64__)
# define VexGuestState VexGuestAMD64State
# define LibVEX_Guest_initialise LibVEX_GuestAMD64_initialise
# define VexArch VexArchAMD64
@@ -143,7 +143,7 @@
switchback_asm(); // never returns
}
=20
-#elif defined(__amd64__)
+#elif defined(__x86_64__)
=20
asm(
"switchback_asm:\n"
@@ -340,7 +340,7 @@
" ret\n"
);
=20
-#elif defined(__amd64__)
+#elif defined(__x86_64__)
asm(
"run_translation_asm:\n"
=20
@@ -656,7 +656,7 @@
gst.guest_ESP =3D esp+4;
next_guest =3D gst.guest_EIP;
}
-# elif defined(__amd64__)
+# elif defined(__x86_64__)
{
HWord esp =3D gst.guest_RSP;
gst.guest_RIP =3D *(UInt*)(esp+0);
@@ -772,7 +772,7 @@
gst.guest_ESP =3D (UInt)&gstack[25000];
*(UInt*)(gst.guest_ESP+4) =3D (UInt)serviceFn;
*(UInt*)(gst.guest_ESP+0) =3D 0x12345678;
-# elif defined(__amd64__)
+# elif defined(__x86_64__)
gst.guest_RIP =3D (ULong)entry;
gst.guest_RSP =3D (ULong)&gstack[25000];
gst.guest_RDI =3D (ULong)serviceFn;
|
|
From: <sv...@va...> - 2005-03-29 21:33:15
|
Author: sewardj
Date: 2005-03-29 22:33:11 +0100 (Tue, 29 Mar 2005)
New Revision: 1110
Modified:
trunk/priv/guest-x86/toIR.c
Log:
Fix incorrect DIP.
Modified: trunk/priv/guest-x86/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-x86/toIR.c 2005-03-29 21:32:41 UTC (rev 1109)
+++ trunk/priv/guest-x86/toIR.c 2005-03-29 21:33:11 UTC (rev 1110)
@@ -11072,7 +11072,7 @@
/* and move %ESP back up */
putIReg( 4, R_ESP, binop(Iop_Add32, mkexpr(t5), mkU32(8*4)) );
=20
- DIP("pusha%c\n", nameISize(sz));
+ DIP("popa%c\n", nameISize(sz));
break;
=20
case 0x8F: /* POPL/POPW m32 */
|
|
From: <sv...@va...> - 2005-03-29 21:32:47
|
Author: sewardj
Date: 2005-03-29 22:32:41 +0100 (Tue, 29 Mar 2005)
New Revision: 1109
Modified:
trunk/priv/main/vex_main.c
trunk/priv/main/vex_util.c
Log:
Increase default max bb size from 50 to 60 guest instructions.
Modified: trunk/priv/main/vex_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/main/vex_main.c 2005-03-28 00:46:27 UTC (rev 1108)
+++ trunk/priv/main/vex_main.c 2005-03-29 21:32:41 UTC (rev 1109)
@@ -77,7 +77,7 @@
vcon->iropt_level =3D 2;
vcon->iropt_precise_memory_exns =3D False;
vcon->iropt_unroll_thresh =3D 120;
- vcon->guest_max_insns =3D 50;
+ vcon->guest_max_insns =3D 60;
vcon->guest_chase_thresh =3D 10;
}
=20
Modified: trunk/priv/main/vex_util.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/main/vex_util.c 2005-03-28 00:46:27 UTC (rev 1108)
+++ trunk/priv/main/vex_util.c 2005-03-29 21:32:41 UTC (rev 1109)
@@ -51,7 +51,7 @@
MByte/sec. Once the size increases enough to fall out of the cache
into memory, the rate falls by about a factor of 3.=20
*/
-#define N_TEMPORARY_BYTES 1000000
+#define N_TEMPORARY_BYTES 1200000
=20
static Char temporary[N_TEMPORARY_BYTES];
static Int temporary_used =3D 0;
|
|
From: Jeremy F. <je...@go...> - 2005-03-29 16:57:24
|
Tom Hughes wrote:
>I've got a PIE build of valgrind running on amd64 now but in order
>to do it I had to add four extra arguments to VG_(run_innerloop) so
>that the assembly in dispatch.S wouldn't need to reference any global
>variables.
>
>Basically the prototype for VG_(run_innerloop) now looks like this:
>
> extern UInt VG_(run_innerloop) ( void* guest_state,
> OffT instr_ptr_offset,
> UInt *dispatch_ctr_ptr,
> ULong *tt_fast[],
> UInt *tt_fastN[] );
>
>The necessary changes in the assembly code add three loads to the fast
>path in dispatch_boring as things stand. One of those might be avoidable
>if the value of VG_(dispatch_ctr) was cached locally and the global was
>only updated on exit from VG_(run_innerloop).
>
>Does anybody have any suggestions for a better way to make the code
>in dispatch.S position independent?
>
>
You could just use globals and make position-independent references to
them. Look at the gcc -S output to see what the syntax is; I have a
patch somewhere which does this, but I can't find it right now.
J
|
|
From: Julian S. <js...@ac...> - 2005-03-29 16:39:21
|
On Tuesday 29 March 2005 14:53, Tom Hughes wrote:
> A number of routines in vg_mylibc.c are simple wrappers around
> system calls which means that they are OS and/or platform specific
> and shouldn't be in the core code. In fact a number of them are
> currently disabled on amd64 because the system call they need to
> make is different there to x86-linux.
>
> One obvious answer would be to move them into the linux or
> x86-linux/amd64-linux directories as appropriate. They would
> to keep the VG_() designation though as it would be OS dependent
> whether they needed to be in the OS or platform directory and
> therefore have a VGO_() or VGP() designation.
>
> The only one that have been moved so far seems to be mmap which
> was done by creating a VGP_DO_MMAP macro although that is also
> used in a number of other places.
>
> Does anybody have any opinions on how best to deal with with
> this? and is anybody already working on resolving this or is
> it clear for me to take a look at it?
It certainly needs cleaning up. I mused on this a while back.
What I want to happen is for a Kernel-services Abstraction Layer
(Kal) to appear. In the same way that Moz has NPSR, OOo has
SAL, etc. Kal will provide services like mmap etc whilst hiding
the details of how the call is done on different platforms. Of
course Kal will be far simpler than NPSR, SAL, etc, but the idea
is the same.
So that's something worth looking into. I plan to do this myself
anyway at some stage, but if you want to look into it, please do.
A related problem is that in various places there are
direct use of syscalls (viz, do_syscallN(args)). This is
at odds with portability, and those should be replaced with
calls to the Kal interface. My intention is that, apart from
the syscall wrappers, doing syscalls directly is banned: all
requests for kernel services must go through Kal.
Another thing is that I don't think the current division of the
source base into generic stuff, x86 stuff, amd64 stuff, etc, is
necessarily the best top-level structure. Although it does
separate out the plat-dependent stuff, it obscures module
boundaries -- which imo are the most important thing to have
a clear picture of, from a maintenance/understanding point of view.
This is because, for example, to build such a Kal module, you
would have some generic stuff in one set of dirs/files, but also
bits of Kal scattered in the x86-linux, amd64-linux, etc, trees.
Instead, it would be better to put the Kal module/subsystem
in its own directory, kal, and put all the arch/os specific bits
just for Kal in there:
kal/pub_core_kal.h -- services exported from kal; core but not
tools may use these
kal/pub_tool_kal.h -- services exported from kal; both core and
tools may use these
kal/any_other_name.h -- private header files for use only within
kal/
kal/kal-x86-linux.c -- x86-linux specific implementation
kal/kal-amd64-linux.c -- amd64-linux specific implementation
kal/any_other_name.c -- generic implementation
I hope to diffuse the code base towards this kind of module structure
on an ongoing basis. An auxiliary idea is then to have a perl script
which runs at build time, which examines #include statements and
thereby mechanically enforces the requirement that only the publically
visible interfaces of each module are used outside of that module.
J
|
|
From: Julian S. <js...@ac...> - 2005-03-29 16:37:15
|
On Tuesday 29 March 2005 17:07, Tom Hughes wrote: > In message <200...@ac...> > > Julian Seward <js...@ac...> wrote: > > So what you're saying is that later-model Pentium IIs do set fxsr > > and so will be supported, yes? I had thought that all PIIs could > > do that, but evidently not. > > I did some googling earlier and it was introduced with Deschutes > which was a die shrink of the original PII by the looks of it, so > it is only the very earliest PII's that don't have fxsr. Right. So then I guess I have to say to Jeroen, sorry, it ain't going to work on PII-Klamath. J |
|
From: Tom H. <to...@co...> - 2005-03-29 16:07:10
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So what you're saying is that later-model Pentium IIs do set fxsr
> and so will be supported, yes? I had thought that all PIIs could
> do that, but evidently not.
I did some googling earlier and it was introduced with Deschutes
which was a die shrink of the original PII by the looks of it, so
it is only the very earliest PII's that don't have fxsr.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-29 15:58:29
|
> Requiring fxsr will also rule P5, P5-MMX and P6 processors as well > as older AMD processors like the K6. I'm not terribly bothered about not supporting P5, P5-MMX, K6 or Pentium-Pro. At some point there's a diminishing tail which it's not worth the hassle of supporting -- I'm saying that this tail includes anything that can't at least do fxsave and fxrstor. So what you're saying is that later-model Pentium IIs do set fxsr and so will be supported, yes? I had thought that all PIIs could do that, but evidently not. J |
|
From: Julian S. <js...@ac...> - 2005-03-29 15:39:51
|
> Does anybody have any suggestions for a better way to make the code > in dispatch.S position independent? Yes. One thing that might work is to create a struct holding dispatch_ctr, tt_fast and tt_fastN, and pass in a pointer to the struct. This reduces the fast-path cost to one load per iteration, which isn't so bad. It sounds a bit ugly though. I'll have a look at it later this evening. J |
|
From: Tom H. <to...@co...> - 2005-03-29 13:53:09
|
A number of routines in vg_mylibc.c are simple wrappers around system calls which means that they are OS and/or platform specific and shouldn't be in the core code. In fact a number of them are currently disabled on amd64 because the system call they need to make is different there to x86-linux. One obvious answer would be to move them into the linux or x86-linux/amd64-linux directories as appropriate. They would to keep the VG_() designation though as it would be OS dependent whether they needed to be in the OS or platform directory and therefore have a VGO_() or VGP() designation. The only one that have been moved so far seems to be mmap which was done by creating a VGP_DO_MMAP macro although that is also used in a number of other places. Does anybody have any opinions on how best to deal with with this? and is anybody already working on resolving this or is it clear for me to take a look at it? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2005-03-29 13:38:27
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> But with valgrind 3.0.0.SVN, I get this:
>>
>> valgrind: fatal error: unsupported CPU.
>> Supported CPUs are:
>> * x86 with SSE state (Pentium II or above, AMD Athlon or above)
>>
>> Is this a problem in valgrind 3.0, or a missing restriction in the 3.0
>> documentation? Should I file a bug report about this?
>
> The 3.0 line should work on PIIs, but I don't have one to test it on,
> hence I'm not surprised there's a problem.
>
> Have a poke around in coregrind/x86/state.c,
> function VGA_(getArchAndSubArch). It should be that have_sse0 is
> set to True and have_sse1 and have_sse2 are set to False, but I
> guess that is not happening right.
For have_sse0 to get set the fxsr bit has to be set in the
capabilities and according to the cpuinfo output that was posted
the processor in question didn't have that bit set.
I have a PII here that does have it set however:
model name : Pentium II (Deschutes)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
Note that it is a "Deschutes" processor not a "Klamath" so it is
obviously a later model that added some extra features (specifically
the apic, pat, pse36 and fxsr flags).
Requiring fxsr will also rule P5, P5-MMX and P6 processors as well
as older AMD processors like the K6.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-03-29 12:18:54
|
In message <yek...@ho...>
Tom Hughes <to...@co...> wrote:
> I also can't currently get valgrind to load above 0xf0000000 as it
> just segfaults while loading the client program if I try.
The fix to ROUNDDN that I just checked it solves this problem
so with a PIE valgrind I now have a memory map that looks like
this:
client_base 0x0 (174161MB)
client_mapbase 0x2A85154000 (348845MB)
client_end 0x7FAFF00000 (1MB)
shadow_base 0x7FB0000000 (0MB)
shadow_end 0x7FB0000000
valgrind_base 0x7FB0000000 (255MB)
valgrind_last 0x7FBFFFFFFF
Hopefully that should be enough address space for our more demanding
users to be going on with ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-29 09:34:45
|
> The necessary changes in the assembly code add three loads to the fast > path in dispatch_boring as things stand. Hmm, that's not good. What does the resulting version of run_innerloop look like? J |
|
From: Tom H. <to...@co...> - 2005-03-29 09:14:33
|
I've got a PIE build of valgrind running on amd64 now but in order
to do it I had to add four extra arguments to VG_(run_innerloop) so
that the assembly in dispatch.S wouldn't need to reference any global
variables.
Basically the prototype for VG_(run_innerloop) now looks like this:
extern UInt VG_(run_innerloop) ( void* guest_state,
OffT instr_ptr_offset,
UInt *dispatch_ctr_ptr,
ULong *tt_fast[],
UInt *tt_fastN[] );
The necessary changes in the assembly code add three loads to the fast
path in dispatch_boring as things stand. One of those might be avoidable
if the value of VG_(dispatch_ctr) was cached locally and the global was
only updated on exit from VG_(run_innerloop).
Does anybody have any suggestions for a better way to make the code
in dispatch.S position independent?
Note that vex also has to be built with EXTRA_CFLAGS="-fpie" in order
to get a PIE build of valgrind.
I also can't currently get valgrind to load above 0xf0000000 as it
just segfaults while loading the client program if I try.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2005-03-29 03:05:00
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-29 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: (skipping, prereq failed: ../../../tests/cputest x86-mmxext) insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |