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: Julian S. <js...@ac...> - 2005-03-30 23:39:13
|
> I'll fix that up and get it committed then. The x86 side should > really have the same change, but we can get away without it there > because the dynamic linker will do relocations at load time for > code that isn't really PIC but ought to be - the amd64 one won't > do that. Cool. I guess there's also a net performance loss putting the same change in x86. Yeh. I guess it can't, because insns with offsets don't carry 64-bit offsets. Or something. I just had a spin with konq and moz startups on amd64. Looks promising, mostly a lot of complaining about missing syscalls which ultimately causes moz to give up and konq to not be able to do anything due to not being able to communicate with dcopserver. Small KDE apps (kmines, kpat, kcalc) work, more or less. Unfortunately SuSE seem to have neglected to ship that most useful of KDE applications, ktuberling ;-) J |
|
From: <sv...@va...> - 2005-03-30 23:36:32
|
Author: tom Date: 2005-03-31 00:36:28 +0100 (Thu, 31 Mar 2005) New Revision: 3486 Modified: trunk/coregrind/amd64/dispatch.S Log: Make the dispatcher code position independent so that PIE mode works. Modified: trunk/coregrind/amd64/dispatch.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/coregrind/amd64/dispatch.S 2005-03-30 19:31:18 UTC (rev 3485) +++ trunk/coregrind/amd64/dispatch.S 2005-03-30 23:36:28 UTC (rev 3486) @@ -60,8 +60,12 @@ pushq %r15 pushq %rdi =20 - /* 0(%rsp) holds cached copy of guest_state */ + movq VG_(dispatch_ctr)@GOTPCREL(%rip), %rsi + pushq (%rsi) =20 + /* 8(%rsp) holds cached copy of guest_state */ + /* 0(%rsp) holds cached copy of VG_(dispatch_ctr) */ + /* Set up the guest state pointer */ movq %rdi, %rbp =09 @@ -95,17 +99,19 @@ movq %rax, OFFSET_amd64_RIP(%rbp) =20 /* Are we out of timeslice? If yes, defer to scheduler. */ - subl $1, VG_(dispatch_ctr) + subl $1, 0(%rsp) jz counter_is_zero =20 /* try a fast lookup in the translation cache */ movq %rax, %rbx andq $VG_TT_FAST_MASK, %rbx - movq VG_(tt_fast)(,%rbx,8), %rcx + movq VG_(tt_fast)@GOTPCREL(%rip), %rcx + movq (%rcx,%rbx,8), %rcx cmpq %rax, (%rcx) jnz fast_lookup_failed /* increment bb profile counter */ - movq VG_(tt_fastN)(,%rbx,8), %rdx + movq VG_(tt_fastN)@GOTPCREL(%rip), %rdx + movq (%rdx,%rbx,8), %rdx incl (%rdx) =20 /* Found a match. Call tce[1], which is 8 bytes along, since @@ -118,13 +124,13 @@ %rbp indicates further details of the control transfer requested to the address in %rax. =09 - If rbp is unchanged (=3D=3D * 0(%rsp)), just jump next to %rax. + If rbp is unchanged (=3D=3D * 8(%rsp)), just jump next to %rax. =20 Otherwise fall out, back to the scheduler, and let it figure out what to do next. */ =20 - cmpq 0(%rsp), %rbp + cmpq 8(%rsp), %rbp jz dispatch_boring =20 jmp dispatch_exceptional @@ -157,6 +163,8 @@ jmp run_innerloop_exit_REALLY =20 run_innerloop_exit_REALLY: + movq VG_(dispatch_ctr)@GOTPCREL(%rip), %rsi + popq (%rsi) popq %rdi popq %r15 popq %r14 @@ -184,20 +192,20 @@ jz counter_is_zero =20 /* save %rax in %RIP and defer to sched */ - movq 0(%rsp), %rdi + movq 8(%rsp), %rdi movq %rax, OFFSET_amd64_RIP(%rdi) movq %rbp, %rax jmp run_innerloop_exit =20 fast_lookup_failed: /* %RIP is up to date here since dispatch_boring dominates */ - addl $1, VG_(dispatch_ctr) + addl $1, 0(%rsp) movq $VG_TRC_INNER_FASTMISS, %rax jmp run_innerloop_exit =20 counter_is_zero: /* %RIP is up to date here since dispatch_boring dominates */ - addl $1, VG_(dispatch_ctr) + addl $1, 0(%rsp) movq $VG_TRC_INNER_COUNTERZERO, %rax jmp run_innerloop_exit =20 |
|
From: <sv...@va...> - 2005-03-30 23:20:51
|
Author: sewardj
Date: 2005-03-31 00:20:47 +0100 (Thu, 31 Mar 2005)
New Revision: 1115
Modified:
trunk/priv/guest-amd64/toIR.c
trunk/priv/host-amd64/hdefs.c
trunk/priv/host-amd64/isel.c
Log:
Support a few more insns I ran across whilst trying to start up
konqueror (mostly successfully) and mozilla (promising but
unsuccessful).
Modified: trunk/priv/guest-amd64/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-amd64/toIR.c 2005-03-30 23:19:46 UTC (rev 1114)
+++ trunk/priv/guest-amd64/toIR.c 2005-03-30 23:20:47 UTC (rev 1115)
@@ -3605,9 +3605,9 @@
case 4: /* MUL (unsigned widening) */
codegen_mulL_A_D ( sz, False, t1, dis_buf );
break;
-//.. case 5: /* IMUL */
-//.. codegen_mulL_A_D ( sz, True, t1, dis_buf );
-//.. break;
+ case 5: /* IMUL */
+ codegen_mulL_A_D ( sz, True, t1, dis_buf );
+ break;
case 6: /* DIV */
codegen_div ( sz, t1, False );
DIP("div%c %s\n", nameISize(sz), dis_buf);
@@ -8060,11 +8060,12 @@
goto decode_success;
}
=20
-//.. /* 0F 55 =3D ANDNPS -- G =3D (not G) and E */
-//.. if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x55) {
-//.. delta =3D dis_SSE_E_to_G_all_invG( sorb, delta+2, "andnps", I=
op_And128 );
-//.. goto decode_success;
-//.. }
+ /* 0F 55 =3D ANDNPS -- G =3D (not G) and E */
+ if (haveNo66noF2noF3(pfx) && sz =3D=3D 4=20
+ && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x55) {
+ delta =3D dis_SSE_E_to_G_all_invG( pfx, delta+2, "andnps", Iop_And=
V128 );
+ goto decode_success;
+ }
=20
/* 0F 54 =3D ANDPS -- G =3D G and E */
if (haveNo66noF2noF3(pfx) && sz =3D=3D 4=20
@@ -8078,14 +8079,14 @@
//.. delta =3D dis_SSEcmp_E_to_G( sorb, delta+2, "cmpps", True, 4 =
);
//.. goto decode_success;
//.. }
-//..=20
-//.. /* F3 0F C2 =3D CMPSS -- 32F0x4 comparison from R/M to R */
-//.. if (insn[0] =3D=3D 0xF3 && insn[1] =3D=3D 0x0F && insn[2] =3D=3D=
0xC2) {
-//.. vassert(sz =3D=3D 4);
-//.. delta =3D dis_SSEcmp_E_to_G( sorb, delta+3, "cmpss", False, 4=
);
-//.. goto decode_success;
-//.. }
=20
+ /* F3 0F C2 =3D CMPSS -- 32F0x4 comparison from R/M to R */
+ if (haveF3no66noF2(pfx) && sz =3D=3D 4
+ && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0xC2) {
+ delta =3D dis_SSEcmp_E_to_G( pfx, delta+2, "cmpss", False, 4 );
+ goto decode_success;
+ }
+
/* 0F 2F =3D COMISS -- 32F0x4 comparison G,E, and set ZCP */
/* 0F 2E =3D UCOMISS -- 32F0x4 comparison G,E, and set ZCP */
if (haveNo66noF2noF3(pfx) && sz =3D=3D 4=20
@@ -8700,12 +8701,13 @@
goto decode_success;
}
=20
-//.. /* 0F 56 =3D ORPS -- G =3D G and E */
-//.. if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x56) {
-//.. delta =3D dis_SSE_E_to_G_all( sorb, delta+2, "orps", Iop_Or12=
8 );
-//.. goto decode_success;
-//.. }
-//..=20
+ /* 0F 56 =3D ORPS -- G =3D G and E */
+ if (haveNo66noF2noF3(pfx) && sz =3D=3D 4
+ && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x56) {
+ delta =3D dis_SSE_E_to_G_all( pfx, delta+2, "orps", Iop_OrV128 );
+ goto decode_success;
+ }
+
//.. /* ***--- this is an MMX class insn introduced in SSE1 ---*** */
//.. /* 0F E0 =3D PAVGB -- 8x8 unsigned Packed Average, with rounding=
*/
//.. if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0xE0) {
Modified: trunk/priv/host-amd64/hdefs.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/host-amd64/hdefs.c 2005-03-30 23:19:46 UTC (rev 1114)
+++ trunk/priv/host-amd64/hdefs.c 2005-03-30 23:20:47 UTC (rev 1115)
@@ -3109,7 +3109,7 @@
//.. case Xsse_SQRTF: *p++ =3D 0x51; break;
case Asse_SUBF: *p++ =3D 0x5C; break;
//.. case Xsse_CMPEQF: *p++ =3D 0xC2; xtra =3D 0x100; break;
-//.. case Xsse_CMPLTF: *p++ =3D 0xC2; xtra =3D 0x101; break;
+ case Asse_CMPLTF: *p++ =3D 0xC2; xtra =3D 0x101; break;
//.. case Xsse_CMPLEF: *p++ =3D 0xC2; xtra =3D 0x102; break;
default: goto bad;
}
Modified: trunk/priv/host-amd64/isel.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/host-amd64/isel.c 2005-03-30 23:19:46 UTC (rev 1114)
+++ trunk/priv/host-amd64/isel.c 2005-03-30 23:20:47 UTC (rev 1115)
@@ -2976,6 +2976,16 @@
addInstr(env, AMD64Instr_SseLdSt( True/*load*/, 16, dst, rsp0 )=
);
add_to_rsp(env, 16);
return dst;
+ } else=20
+ if (e->Iex.Const.con->Ico.V128 =3D=3D 0x000F) {
+ HReg tmp =3D newVRegI(env);
+ AMD64AMode* rsp0 =3D AMD64AMode_IR(0, hregAMD64_RSP());
+ addInstr(env, AMD64Instr_Imm64(0xFFFFFFFFULL, tmp));
+ addInstr(env, AMD64Instr_Push(AMD64RMI_Imm(0)));
+ addInstr(env, AMD64Instr_Push(AMD64RMI_Reg(tmp)));
+ addInstr(env, AMD64Instr_SseLdSt( True/*load*/, 16, dst, rsp0 )=
);
+ add_to_rsp(env, 16);
+ return dst;
} else {
goto vec_fail;
# if 0
@@ -3238,7 +3248,7 @@
//.. }
=20
//.. case Iop_CmpEQ32F0x4: op =3D Xsse_CMPEQF; goto do_32F0x4;
-//.. case Iop_CmpLT32F0x4: op =3D Xsse_CMPLTF; goto do_32F0x4;
+ case Iop_CmpLT32F0x4: op =3D Asse_CMPLTF; goto do_32F0x4;
//.. case Iop_CmpLE32F0x4: op =3D Xsse_CMPLEF; goto do_32F0x4;
case Iop_Add32F0x4: op =3D Asse_ADDF; goto do_32F0x4;
case Iop_Div32F0x4: op =3D Asse_DIVF; goto do_32F0x4;
|
|
From: <sv...@va...> - 2005-03-30 23:19:52
|
Author: sewardj
Date: 2005-03-31 00:19:46 +0100 (Thu, 31 Mar 2005)
New Revision: 1114
Modified:
trunk/priv/ir/iropt.c
Log:
Add a folding rule for Mul64.
Modified: trunk/priv/ir/iropt.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/ir/iropt.c 2005-03-30 18:40:23 UTC (rev 1113)
+++ trunk/priv/ir/iropt.c 2005-03-30 23:19:46 UTC (rev 1114)
@@ -1059,6 +1059,12 @@
(e->Iex.Binop.arg1->Iex.Const.con->Ico.U32
* e->Iex.Binop.arg2->Iex.Const.con->Ico.U32)));
break;
+ case Iop_Mul64:
+ e2 =3D IRExpr_Const(IRConst_U64(
+ (e->Iex.Binop.arg1->Iex.Const.con->Ico.U64
+ * e->Iex.Binop.arg2->Iex.Const.con->Ico.U64)));
+ break;
+
case Iop_MullS32: {
/* very paranoid */
UInt u32a =3D e->Iex.Binop.arg1->Iex.Const.con->Ico.U32;
|
|
From: Jeremy F. <je...@go...> - 2005-03-30 23:18:57
|
Nicholas Nethercote wrote:
> Giving the tool direct access to the VG_(tool_interface) struct
> doesn't seem like a good idea -- it exposes it to more than it needs
> to see.
Agreed.
> So this would simply separate structs corresponding to each of the
> multi-arg functions in the patch now. Only two of those functions are
> really bad -- VG_(needs_tool_errors)() has 8 args, VG_(malloc_funcs)()
> has 10. Do you think we need structs for the ones with only 1, 2 or 3
> args?
It would seem silly to have lots of little structures, but having two
calling styles isn't terribly pretty either (and one presumes that at
some point you'd need to convert a called-with-pointers function to a
called-with-a-struct function when the number of functions reaches a
certain point). I guess structures for the biggies and literal pointers
for the 1,2,3 cases, but I still think a simple one registry function
per function model is cleaner and more robust in the long term.
J
|
|
From: Tom H. <to...@co...> - 2005-03-30 23:16:17
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> That's just too ugly. For the time being, let's go with the
> "movq VG_(tt_fast)@GOTPCREL(%rip), %rcx" style fixes that
> Tom/Jeremy cooked up. Does the x86 side need similar modification
> or is that OK as-is ?
I'll fix that up and get it committed then. The x86 side should
really have the same change, but we can get away without it there
because the dynamic linker will do relocations at load time for
code that isn't really PIC but ought to be - the amd64 one won't
do that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-30 22:51:12
|
Hmm. This is a pig of a problem. With r3484/r3485 I managed to get rid of one insn per fast-iteration, but being PIE still costs us. The "best" solution I can think of is to glom all the dispatcher- visible state (dispatch_ctr, fast[], fastN[]) into a single struct, and pass a pointer to that to run_innerloop. That pointer can be reloaded from the stack each time round the loop, so the extra cost is one insn/bb, which given that one insn was just got rid of, is free, at least in terms of insn counts. So the main difficulty -- apart from the uglyness of inventing a struct purely for this reason -- is how the assembly code can know the (literal) offsets of the struct components, without having to mess around with preprocessor programs to extract the offsets. That's just too ugly. For the time being, let's go with the "movq VG_(tt_fast)@GOTPCREL(%rip), %rcx" style fixes that Tom/Jeremy cooked up. Does the x86 side need similar modification or is that OK as-is ? > Yep, that looks about right. I wasn't too worried about adding a couple > of extra instructions here because BB-chaining should take most of the > load off this code (in 2.4); in 3, one presumes Vex's BB-fusing is about > as effective (or we need to look at doing chaining as well). Further ahead, it would be nice to reinstate bb-chaining. Vex's chasing results in bb count reductions on the order of 20%-30% compared to 2.4, which is a start, and gives indirect benefits in that the guest regs remains cached in host regs across the boundary. Nevertheless this leaves a lot of scope for chaining. For one thing, chaining removes the indirect and presumably unpredictable call that the dispatcher must make. J |
|
From: Julian S. <js...@ac...> - 2005-03-30 20:01:33
|
Thanks. Oops! Now fixed. J On Wednesday 30 March 2005 20:47, Maurice van der Pot wrote: > This is what I get when I visit www.valgrind.org: > > Parse error: parse error, unexpected T_IS_IDENTICAL in > /usr/local/www/sites/valgrind-www/php/.htconfx on line 15 > > Just so you know. > > Maurice. |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-03-30 19:48:19
|
This is what I get when I visit www.valgrind.org: Parse error: parse error, unexpected T_IS_IDENTICAL in /usr/local/www/sites/valgrind-www/php/.htconfx on line 15 Just so you know. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: <sv...@va...> - 2005-03-30 19:31:40
|
Author: sewardj Date: 2005-03-30 20:31:18 +0100 (Wed, 30 Mar 2005) New Revision: 3485 Modified: trunk/coregrind/amd64/dispatch.S Log: Comment-only change Modified: trunk/coregrind/amd64/dispatch.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/coregrind/amd64/dispatch.S 2005-03-30 19:04:29 UTC (rev 3484) +++ trunk/coregrind/amd64/dispatch.S 2005-03-30 19:31:18 UTC (rev 3485) @@ -31,13 +31,15 @@ =20 #include "core_asm.h" #include "amd64_private_asm.h" -#include "libvex_guest_offsets.h" +#include "libvex_guest_offsets.h" /* for OFFSET_amd64_RIP */ =20 =20 /*------------------------------------------------------------*/ /*--- The dispatch loop. ---*/ /*------------------------------------------------------------*/ -=09 + +/* signature: UWord VG_(run_innerloop) ( void* guest_state ) */ + .globl VG_(run_innerloop) VG_(run_innerloop): /* %rdi holds guest_state */ |
|
From: <sv...@va...> - 2005-03-30 19:04:34
|
Author: sewardj
Date: 2005-03-30 20:04:29 +0100 (Wed, 30 Mar 2005)
New Revision: 3484
Modified:
trunk/coregrind/core.h
trunk/coregrind/vg_main.c
trunk/coregrind/vg_scheduler.c
trunk/coregrind/x86/dispatch.S
Log:
Completely get rid of VG_(instr_ptr_offset).
Modified: trunk/coregrind/core.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/coregrind/core.h 2005-03-30 18:42:59 UTC (rev 3483)
+++ trunk/coregrind/core.h 2005-03-30 19:04:29 UTC (rev 3484)
@@ -994,9 +994,6 @@
/* Counts downwards in vg_run_innerloop. */
extern UInt VG_(dispatch_ctr);
=20
-/* Instruction pointer guest state offset, used by $VG_ARCH/dispatch.S. =
*/
-extern OffT VG_(instr_ptr_offset);
-
/* Stats ... */
extern void VG_(print_scheduler_stats) ( void );
=20
@@ -1607,7 +1604,7 @@
address is found in the translation cache. For anything else, the
scheduler does the work.
*/
-extern UInt VG_(run_innerloop) ( void* guest_state );
+extern UWord VG_(run_innerloop) ( void* guest_state );
=20
/* ---------------------------------------------------------------------
Exports of vg_helpers.S
Modified: trunk/coregrind/vg_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/coregrind/vg_main.c 2005-03-30 18:42:59 UTC (rev 3483)
+++ trunk/coregrind/vg_main.c 2005-03-30 19:04:29 UTC (rev 3484)
@@ -148,9 +148,6 @@
Char** VG_(client_argv);
Char** VG_(client_envp);
=20
-// Instruction pointer guest state offset, used by $VG_ARCH/dispatch.S.
-OffT VG_(instr_ptr_offset);
-
/* Indicates what arch and subarch we are running on. */
VexArch VG_(vex_arch) =3D VexArch_INVALID;
VexSubArch VG_(vex_subarch) =3D VexSubArch_INVALID;
@@ -2685,9 +2682,6 @@
VG_TRACK( post_reg_write, Vg_CoreStartup, /*tid*/1, /*offset*/0,
sizeof(VexGuestArchState));
=20
- // Record the instr ptr offset, for use by asm code.
- VG_(instr_ptr_offset) =3D offsetof(VexGuestArchState, VGA_INSTR_PTR);
-
//--------------------------------------------------------------
// Initialise the pthread model
// p: ?
Modified: trunk/coregrind/vg_scheduler.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/coregrind/vg_scheduler.c 2005-03-30 18:42:59 UTC (rev 3483)
+++ trunk/coregrind/vg_scheduler.c 2005-03-30 19:04:29 UTC (rev 3484)
@@ -453,8 +453,6 @@
{
volatile Bool jumped;
volatile ThreadState *tst =3D VG_(get_ThreadState)(tid);
- //volatile Addr EIP =3D tst->arch.m_eip;
- //volatile Addr nextEIP;
=20
volatile UInt trc =3D 0;
volatile Int dispatch_ctr_SAVED =3D VG_(dispatch_ctr);
@@ -495,10 +493,6 @@
vg_assert(sz_spill =3D=3D LibVEX_N_SPILL_BYTES);
vg_assert(a_vex + 2 * sz_vex =3D=3D a_spill);
=20
- vg_assert(VG_(instr_ptr_offset) >=3D 0);
- vg_assert(VG_(instr_ptr_offset) <=3D 10000); /* let's say */
- vg_assert(sizeof VG_(instr_ptr_offset) =3D=3D sizeof(HWord));
-
VGP_PUSHCC(VgpRun);
=20
/* there should be no undealt-with signals */
@@ -509,7 +503,8 @@
vg_assert(VG_(my_fault));
VG_(my_fault) =3D False;
=20
- SCHEDSETJMP(tid, jumped, trc =3D VG_(run_innerloop)( (void*)&tst->arc=
h.vex ));
+ SCHEDSETJMP(tid, jumped,=20
+ trc =3D (UInt)VG_(run_innerloop)( (void*)&tst->arch.=
vex ));
=20
//nextEIP =3D tst->arch.m_eip;
//if (nextEIP >=3D VG_(client_end))
Modified: trunk/coregrind/x86/dispatch.S
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/coregrind/x86/dispatch.S 2005-03-30 18:42:59 UTC (rev 3483)
+++ trunk/coregrind/x86/dispatch.S 2005-03-30 19:04:29 UTC (rev 3484)
@@ -31,14 +31,15 @@
=20
#include "core_asm.h"
#include "x86_private_asm.h"
+#include "libvex_guest_offsets.h" /* for OFFSET_x86_EIP */
=20
=20
/*------------------------------------------------------------*/
/*--- The dispatch loop. ---*/
/*------------------------------------------------------------*/
-=09
-/* signature: UInt VG_(run_innerloop) ( void* guest_state ) */
=20
+/* signature: UWord VG_(run_innerloop) ( void* guest_state ) */
+
.globl VG_(run_innerloop)
VG_(run_innerloop):
/* 4(%esp) holds guest_state */
@@ -57,8 +58,7 @@
movl 28(%esp), %ebp
=09
/* fetch %EIP into %eax */
- movl VG_(instr_ptr_offset), %esi
- movl (%ebp, %esi, 1), %eax
+ movl OFFSET_x86_EIP(%ebp), %eax
=20
/* set host FPU control word to the default mode expected=20
by VEX-generated code. See comments in libvex.h for
@@ -84,8 +84,7 @@
=20
dispatch_boring:
/* save the jump address in the guest state */
- movl VG_(instr_ptr_offset), %esi
- movl %eax, (%ebp, %esi, 1)
+ movl %eax, OFFSET_x86_EIP(%ebp)
=20
/* Are we out of timeslice? If yes, defer to scheduler. */
subl $1, VG_(dispatch_ctr)
@@ -169,9 +168,8 @@
jz counter_is_zero
=20
/* save %eax in %EIP and defer to sched */
- movl VG_(instr_ptr_offset), %esi
movl 28(%esp), %edi
- movl %eax, (%edi, %esi, 1)
+ movl %eax, OFFSET_x86_EIP(%edi)
movl %ebp, %eax
jmp run_innerloop_exit
=20
|
|
From: <sv...@va...> - 2005-03-30 18:45:15
|
Author: de Date: 2005-03-30 19:44:53 +0100 (Wed, 30 Mar 2005) New Revision: 101 Added: trunk/downloads/pmk/ trunk/downloads/pmk/pmk.html Modified: trunk/downloads/variants.html trunk/php/.htconfx Log: Modified website: paul mackerras now has a valgrind email address, and his own dir+page Added: trunk/downloads/pmk/pmk.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/downloads/pmk/pmk.html 2005-03-30 15:57:39 UTC (rev 100) +++ trunk/downloads/pmk/pmk.html 2005-03-30 18:44:53 UTC (rev 101) @@ -0,0 +1,5 @@ +<h3>Paul Mackerras' Stuff</h3> + +<p>Coming soon ... ...</p> + + Modified: trunk/downloads/variants.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/downloads/variants.html 2005-03-30 15:57:39 UTC (rev 100) +++ trunk/downloads/variants.html 2005-03-30 18:44:53 UTC (rev 101) @@ -33,6 +33,11 @@ include './jsf/jsf.html'; break; =20 + case 'pmk': + echo '<a href=3D"/downloads/variants.html">Back</a><br />'."\n"; + include './pmk/pmk.html'; + break; + default: ?> <br /> @@ -55,6 +60,10 @@ other adds support for pool-based allocators.</p> =20 =20 +<p><b>Paul Mackerras</b> has=20 +<a href=3D"/downloads/variants.html?pmk">some stuff too</a>.</p> + + <p><b>Adam Gundy</b> <arg at cyberscience com> supplied a variant of the 20031012 stable release that is capable of running Wine on Valgrind. A big thanks to him.</p> Modified: trunk/php/.htconfx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/php/.htconfx 2005-03-30 15:57:39 UTC (rev 100) +++ trunk/php/.htconfx 2005-03-30 18:44:53 UTC (rev 101) @@ -6,16 +6,17 @@ $included_config =3D true; =20 /*------ change these lines to suit your environment ------*/ -/* --- This is for phoenix --- */ +/* --- This is for phoenix ---=20 $base_url =3D "http://valgrind.local"; $base_dir =3D "/home/de/WebPages/valgrind-www/trunk"; +*/ =20 -/* --- This is for Exonetric --=20 +/* --- This is for Exonetric -- */ $base_url =3D "http://www.valgrind.org"; $base_dir =3D "/usr/local/www/sites/valgrind-www"; -*/ =20 =20 + /*---------------------------------------------------------*/ $config =3D array ( 'base_url' =3D> $base_url, @@ -70,6 +71,10 @@ 'name' =3D> 'Cerion Armour-Brown', 'obfusc' =3D> 'cerion' ), /* cer= ion */ =20 + 'paulus' =3D> array( /* pa...@vg... fwds to: pa...@sa... *= / + 'name' =3D> 'Paul Mackerras', + 'obfusc' =3D> 'paulus' ), /* pau= lus */ + /* val...@vg... fwds to: js...@ac... */ 'valgrind' =3D> 'valgrind', /* we...@vg... fwds to: do...@op...= */ |
|
From: <sv...@va...> - 2005-03-30 18:43:03
|
Author: sewardj
Date: 2005-03-30 19:42:59 +0100 (Wed, 30 Mar 2005)
New Revision: 3483
Modified:
trunk/coregrind/amd64/dispatch.S
Log:
Get rid of the use of VG_(instr_ptr_offset) since we know what that is
at system-build time: OFFSET_amd64_RIP. This saves an instruction on
the fast path, and reduces the number of PIE-difficulties by one.
Modified: trunk/coregrind/amd64/dispatch.S
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/coregrind/amd64/dispatch.S 2005-03-30 18:26:52 UTC (rev 3482)
+++ trunk/coregrind/amd64/dispatch.S 2005-03-30 18:42:59 UTC (rev 3483)
@@ -31,6 +31,7 @@
=20
#include "core_asm.h"
#include "amd64_private_asm.h"
+#include "libvex_guest_offsets.h"
=20
=20
/*------------------------------------------------------------*/
@@ -63,8 +64,7 @@
movq %rdi, %rbp
=09
/* fetch %RIP into %rax */
- movq VG_(instr_ptr_offset), %rsi
- movq (%rbp, %rsi, 1), %rax
+ movq OFFSET_amd64_RIP(%rbp), %rax
=20
/* set host FPU control word to the default mode expected=20
by VEX-generated code. See comments in libvex.h for
@@ -90,8 +90,7 @@
=20
dispatch_boring:
/* save the jump address in the guest state */
- movq VG_(instr_ptr_offset), %rsi
- movq %rax, (%rbp, %rsi, 1)
+ movq %rax, OFFSET_amd64_RIP(%rbp)
=20
/* Are we out of timeslice? If yes, defer to scheduler. */
subl $1, VG_(dispatch_ctr)
@@ -182,10 +181,9 @@
cmpq $VG_TRC_INNER_COUNTERZERO, %rbp
jz counter_is_zero
=20
- /* save %eax in %EIP and defer to sched */
- movq VG_(instr_ptr_offset), %rsi
+ /* save %rax in %RIP and defer to sched */
movq 0(%rsp), %rdi
- movq %rax, (%rdi, %rsi, 1)
+ movq %rax, OFFSET_amd64_RIP(%rdi)
movq %rbp, %rax
jmp run_innerloop_exit
=20
|
|
From: <sv...@va...> - 2005-03-30 18:40:27
|
Author: sewardj
Date: 2005-03-30 19:40:23 +0100 (Wed, 30 Mar 2005)
New Revision: 1113
Modified:
trunk/auxprogs/genoffsets.c
Log:
Generate instruction-pointer offsets too.
Modified: trunk/auxprogs/genoffsets.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/auxprogs/genoffsets.c 2005-03-30 18:20:48 UTC (rev 1112)
+++ trunk/auxprogs/genoffsets.c 2005-03-30 18:40:23 UTC (rev 1113)
@@ -33,6 +33,8 @@
printf("#define OFFSET_x86_ESP %d\n",=20
offsetof(VexGuestX86State,guest_ESP));
=20
+ printf("#define OFFSET_x86_EIP %d\n",=20
+ offsetof(VexGuestX86State,guest_EIP));
=20
=20
printf("#define OFFSET_amd64_RAX %d\n",=20
@@ -56,5 +58,8 @@
printf("#define OFFSET_amd64_R10 %d\n",=20
offsetof(VexGuestAMD64State,guest_R10));
=20
+ printf("#define OFFSET_amd64_RIP %d\n",=20
+ offsetof(VexGuestAMD64State,guest_RIP));
+
return 0;
}
|
|
From: <sv...@va...> - 2005-03-30 18:26:56
|
Author: sewardj Date: 2005-03-30 19:26:52 +0100 (Wed, 30 Mar 2005) New Revision: 3482 Modified: trunk/coregrind/amd64/dispatch.S Log: rm unused function Modified: trunk/coregrind/amd64/dispatch.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/coregrind/amd64/dispatch.S 2005-03-30 15:05:46 UTC (rev 3481) +++ trunk/coregrind/amd64/dispatch.S 2005-03-30 18:26:52 UTC (rev 3482) @@ -32,40 +32,7 @@ #include "core_asm.h" #include "amd64_private_asm.h" =20 -/*------------------------------------------------------------*/ -/*--- The dispatch loop. ---*/ -/*------------------------------------------------------------*/ =20 -.globl switchback -switchback: - /* %rdi -> guest state */ - /* %rsi is rflags */ - movq 0(%rdi), %rax - movq 8(%rdi), %rcx - movq 16(%rdi), %rdx - movq 24(%rdi), %rbx - movq 32(%rdi), %rsp - movq 40(%rdi), %rbp - movq 64(%rdi), %r8 - movq 72(%rdi), %r9 - movq 80(%rdi), %r10 - movq 88(%rdi), %r11 - movq 96(%rdi), %r12 - movq 104(%rdi), %r13 - movq 112(%rdi), %r14 - movq 120(%rdi), %r15 - /* now we need to deal with rsi rdi rflags rip */ - - pushq 168(%rdi) /* %RIP -> stack */ - - pushq %rsi - popfq - - movq 48(%rdi), %rsi - movq 56(%rdi), %rdi - - ret -=09 /*------------------------------------------------------------*/ /*--- The dispatch loop. ---*/ /*------------------------------------------------------------*/ |
|
From: <sv...@va...> - 2005-03-30 18:20:54
|
Author: sewardj
Date: 2005-03-30 19:20:48 +0100 (Wed, 30 Mar 2005)
New Revision: 1112
Modified:
trunk/priv/guest-amd64/toIR.c
Log:
Re-enable 'xchg reg, mem'.
Modified: trunk/priv/guest-amd64/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-amd64/toIR.c 2005-03-29 21:35:08 UTC (rev 1111)
+++ trunk/priv/guest-amd64/toIR.c 2005-03-30 18:20:48 UTC (rev 1112)
@@ -12585,7 +12585,6 @@
nameISize(sz), nameIRegG(sz, pfx, modrm),=20
nameIRegE(sz, pfx, modrm));
} else {
- goto decode_failure; /* awaiting test case */
addr =3D disAMode ( &alen, pfx, delta, dis_buf, 0 );
assign( t1, loadLE(ty, mkexpr(addr)) );
assign( t2, getIRegG(sz, pfx, modrm) );
|
|
From: Julian S. <js...@ac...> - 2005-03-30 18:14:53
|
> Yup. I'm working on it now. Did we ever reach a decision on whether > to drop routines from vg_mylibc that become simple veneers over a > single KAL routine? I think we should -- that is, there's no point in calling into mylibc if that then calls onwards to KAL and does nothing else. In other words mylibc becomes more or less split into two parts: KAL for dealing with the kernel, and whatever is left over in mylibc, which is presumably vanilla stuff like strlen etc. Does that sound sensible? J |
|
From: Tom H. <to...@co...> - 2005-03-30 18:06:51
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > >> I think we should just use the libc API for this, if not the system
> > >> glibc.
> > >
> > > Yes. The above suggestion effectively enshrines that, modulo
> > > perhaps sidestepping the errno uglyness for returning error codes.
> >
> > Well the other thing that I did for several routines was to use
> > a simpler interface that didn't rely on kernel structures, so for
> > example gettimeofday just returns a ULong and nanosleep takes a
> > ULong rather than faffing about with a structure.
>
> That I like -- it sounds like a good thing. In fact, we need to not
> have any kernel types, structs or consts in the kal interface.
The real point I was trying to make was that I wasn't sticking
religiously to the libc interface and creating a kal_timeval struct
but was doing whatever was easiest for the caller to use.
> > Likewise for getrlimit/setrlimit which were the other ones where I
> > made an attempt to remove VKI types from the interface.
>
> Yup.
>
> I presume you'll have an updated patch after a bit more iteration?
Yup. I'm working on it now. Did we ever reach a decision on whether
to drop routines from vg_mylibc that become simple veneers over a
single KAL routine?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-30 16:36:57
|
> > That looks like an excellent start. Does it compile/build on both > > x86 and amd64? > > It does now - the version I sent before had a few minor issues > on x86 but I've just fixed them. Cool. > Yep, the whole question of error codes was another thing that was > a bit thorny when I was doing it. I mostly tried to push the is_kerror > tests down into KAL but some of them are still outside which is wrong. I entirely agree. > I agree that we really want out of band error reporting, which means > either reserving the return value for the error and returning any > other values through reference arguments, or adding an error argument > to each routine, or using a global. A global (errno) is ugly and gives problems should we ever get into a genuinely multithreaded environment. Returning the normal return as a ref param is a bit cumbersome, because often we want to see the return value but ignore the error value (eg, kal_getpid; that cannot fail). Hence it seems to me the cleanest solution is for the error value to be a var parameter which we mandate always to be the first param. We allow it to be NULL. Then we can conveniently do pid = VG_(kal_getpid)(NULL); which is not excessively intrusive. > > In either case we'd need an kal-specific enum holding error codes > > (KAL_EINVAL, KAL_EBADF, etc), and, for each target, a function > > which converts kernel return values for the target into KAL_E* > > values. > > Sounds about right. Error codes presumably have to be in the tool > visible header, along with any structures that tool visible functions > want to use in their interface. Sounds exactly right. > >> I think we should just use the libc API for this, if not the system > >> glibc. > > > > Yes. The above suggestion effectively enshrines that, modulo > > perhaps sidestepping the errno uglyness for returning error codes. > > Well the other thing that I did for several routines was to use > a simpler interface that didn't rely on kernel structures, so for > example gettimeofday just returns a ULong and nanosleep takes a > ULong rather than faffing about with a structure. That I like -- it sounds like a good thing. In fact, we need to not have any kernel types, structs or consts in the kal interface. > Likewise for getrlimit/setrlimit which were the other ones where I > made an attempt to remove VKI types from the interface. Yup. I presume you'll have an updated patch after a bit more iteration? J |
|
From: Tom H. <to...@co...> - 2005-03-30 16:29:19
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Wednesday 30 March 2005 16:15, Nicholas Nethercote wrote:
>
> > If nothing else, the kal_* functions may as well be called
> > VG_(getpid)(), etc, rather than either changing all the callers or
> > having a file full of stub functions.
>
> No ... I prefer to keep the kal_ prefix. It isn't intrusive and
> it avoids the burden of having to remember whether VG_(obscure_foo)
> is a Kal function or not. In the same way that all the POSIX
> pthreads functions and types are trivially identifiable from their
> names.
The other option of course is a new VGK_() or VGKAL_() prefix.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-30 16:15:23
|
On Wednesday 30 March 2005 16:15, Nicholas Nethercote wrote: > On Wed, 30 Mar 2005, Tom Hughes wrote: > >> 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 > > > > How are we going to decide what is and isn't exported? Do we make > > everything core only to start with and move it to the tool header > > if a tool needs it? or make everything available to tools unless > > we have some reason to believe it can only work in the core? > > The former; the tool should see as little as possible. That's how it has > been done in core.h and tool.h. Yup. Tools may see only a subset of what the core may see. So (as is the case with Tom's patch) tool.h exports as little as possible, and as much as possible (here, everything) is in core.h. The only change then needed is that core.h #includes tool.h so as to guarantee the subset/superset relation. > >> 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'm not sure you can have a generic implementation of anything in the > > kernel abstraction layer ;-) > > I guess it depends on whether you keep as a separate layer, as you did in > the patch, or fold that into KAL. I presume you're referring to what to do about VG_(strlen) et al? I think those could go in a different module as they are all pretty harmless. > If nothing else, the kal_* functions may as well be called > VG_(getpid)(), etc, rather than either changing all the callers or > having a file full of stub functions. No ... I prefer to keep the kal_ prefix. It isn't intrusive and it avoids the burden of having to remember whether VG_(obscure_foo) is a Kal function or not. In the same way that all the POSIX pthreads functions and types are trivially identifiable from their names. J |
|
From: Tom H. <to...@co...> - 2005-03-30 16:08:47
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > 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.
>
> That looks like an excellent start. Does it compile/build on both
> x86 and amd64?
It does now - the version I sent before had a few minor issues
on x86 but I've just fixed them.
>> 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.
>
> I guess kal basically implements a tiny subset of libc functionality.
> We need to consider a way to deal with returning error values.
> Currently those functions return -1 if there's a problem, but:
>
> * that precludes them returning -1 as a legitimate return value
>
> * having -1 as the only return value may not give enough detail
> for the caller to diagnose an error return and take appropriate
> action
>
> Not sure how to fix this. We could copy the libc madness and have
> an errno which gets set with a value indicating the problem.
> Or we could give all kal functions an Int* first parameter into
> which an error value is written if there is an error.
Yep, the whole question of error codes was another thing that was
a bit thorny when I was doing it. I mostly tried to push the is_kerror
tests down into KAL but some of them are still outside which is wrong.
I agree that we really want out of band error reporting, which means
either reserving the return value for the error and returning any
other values through reference arguments, or adding an error argument
to each routine, or using a global.
> In either case we'd need an kal-specific enum holding error codes
> (KAL_EINVAL, KAL_EBADF, etc), and, for each target, a function
> which converts kernel return values for the target into KAL_E*
> values.
Sounds about right. Error codes presumably have to be in the tool
visible header, along with any structures that tool visible functions
want to use in their interface.
>> I think we should just use the libc API for this, if not the system
>> glibc.
>
> Yes. The above suggestion effectively enshrines that, modulo
> perhaps sidestepping the errno uglyness for returning error codes.
Well the other thing that I did for several routines was to use
a simpler interface that didn't rely on kernel structures, so for
example gettimeofday just returns a ULong and nanosleep takes a
ULong rather than faffing about with a structure.
Likewise for getrlimit/setrlimit which were the other ones where I
made an attempt to remove VKI types from the interface.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-03-30 15:57:44
|
Author: de Date: 2005-03-30 16:57:39 +0100 (Wed, 30 Mar 2005) New Revision: 100 Modified: trunk/devel/cvs_svn.html Log: Patched 'svn co' lines to actually DTRT=20 (thanks Tom) Modified: trunk/devel/cvs_svn.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/devel/cvs_svn.html 2005-03-26 18:08:49 UTC (rev 99) +++ trunk/devel/cvs_svn.html 2005-03-30 15:57:39 UTC (rev 100) @@ -46,12 +46,12 @@ the 3.0 line has been split into two pieces: Vex, a library that provides dynamic translation services, and Valgrind proper. You=20 need both pieces. Do this:<br /> -<code> svn co svn://svn.valgrind.org/vex/trunk</code><br /> -<code> svn co svn://svn.valgrind.org/valgrind/trunk</code><b= r /> -<code> cd vex/trunk && make clean version all</code><br /> -<code> cd valgrind/trunk</code><br /> +<code> svn co svn://svn.valgrind.org/vex/trunk vex</code><br= /> +<code> svn co svn://svn.valgrind.org/valgrind/trunk valgrind= </code><br /> +<code> cd vex && make clean version all</code><br /> +<code> cd valgrind</code><br /> <code> ./autogen.sh</code><br /> -<code> ./configure --prefix=3D... --with-vex=3D/path/to/vex/= trunk</code><br /> +<code> ./configure --prefix=3D... --with-vex=3D/path/to/vex<= /code><br /> <code> make install</code><br /> </p> =20 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 15:23:30
|
[oh, I forgot to send this the other day, sorry...]
On Mon, 28 Mar 2005, Jeremy Fitzhardinge wrote:
> Well, a function with 15 (or even 8) arguments is always going to be hard to
> read, and hard to write or modify (it's impossible to remember what order
> they should go in, and very easy to stuff it up by adding or deleting an
> argument - in either case you need to carefully check the call against the
> function prototype).
>
> Are you saying that the needs functions are, by definition, all-or-none
At the moment, yes.
> so that if you want to add a new function with is related but not
> essential (say, get_extra_address_info) would actually be a different
> need? Or that a tool would be always required to implement a function
> because of the all-or-none policy, even if its a nul implementation?
The latter; that's how it currently works.
There are currently 6 needs that require the tool to implement functions:
needs_tool_errors, needs_basic_block_discards, needs_command_line_options,
needs_client_requests, needs_syscall_wrapper, needs_sanity_checks.
Of these, only for sanity_checks and syscall_wrapper would it make sense
for any of the tool-supplied functions to be missing or empty. (Oh, and
maybe update_extra() for needs_tool_errors can be sensibly empty).
Also, if a tool replaces malloc, it needs to provide all those functions.
> I'm all for grouping the interface callback registrations into functionally
> related pieces, but it seems like a stretch to further assert that functional
> grouping == all-or-none.
It's not always true, but it's mostly true, and providing empty functions
doesn't seem too onerous. For example, Nulgrind has empty post_clo_init
and fini functions. I guess we could allow:
VG_(basic_tool_funcs)(NULL,
nl_instrument,
NULL)
I don't think there's a clear best answer. Grouping them as I've done
forces a tool to provide empty definitions of any optional functions,
which is not good, but prevents tools from forgetting to provide all the
necessary definitions.
N
|
|
From: Julian S. <js...@ac...> - 2005-03-30 15:19:13
|
> > 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. Tom That looks like an excellent start. Does it compile/build on both x86 and 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. I guess kal basically implements a tiny subset of libc functionality. We need to consider a way to deal with returning error values. Currently those functions return -1 if there's a problem, but: * that precludes them returning -1 as a legitimate return value * having -1 as the only return value may not give enough detail for the caller to diagnose an error return and take appropriate action Not sure how to fix this. We could copy the libc madness and have an errno which gets set with a value indicating the problem. Or we could give all kal functions an Int* first parameter into which an error value is written if there is an error. In either case we'd need an kal-specific enum holding error codes (KAL_EINVAL, KAL_EBADF, etc), and, for each target, a function which converts kernel return values for the target into KAL_E* values. Comments? > I think we should just use the libc API for this, if not the system > glibc. Yes. The above suggestion effectively enshrines that, modulo perhaps sidestepping the errno uglyness for returning error codes. > Would uclibc be a good basis (http://www.uclibc.org/)? It would > get us out of the business of maintaining a C library as well. Currently we only use a tiny subset of the libc functionality. Its behaviour is well defined and understood and we haven't had a problem maintaining it. If we were going to use most/all of libc then uclibc might be a good choice. But considering that we don't have a maintenance problem, using someone else's libc just imports another load of assumptions and constraints to work around, and I don't want that. Besides, it would then constrain us to platforms on which uclibc works. J |