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
(5) |
2
(16) |
3
(23) |
|
4
(13) |
5
(1) |
6
(1) |
7
(17) |
8
(18) |
9
(14) |
10
(12) |
|
11
|
12
(6) |
13
(19) |
14
(4) |
15
(7) |
16
(30) |
17
(12) |
|
18
(2) |
19
(13) |
20
(3) |
21
(3) |
22
(17) |
23
(16) |
24
(5) |
|
25
(14) |
26
(15) |
27
(4) |
28
(15) |
29
(16) |
30
(16) |
31
(15) |
|
From: Julian S. <js...@ac...> - 2013-08-01 16:39:19
|
Hi Maran, Petar, On 07/11/2013 08:12 AM, Maran Pakkirisamy wrote: > On 07/10/2013 05:12 PM, Julian Seward wrote: >> Anyway: I have modified the amd64, x86 and ARM back ends to deal >> with this, and I will do the ppc32 and ppc64 back ends later this >> week. I could probably do the mips32/64 cases if I could find a >> working gcc-compile-farm MIPS machine, which I can't. But I can't >> do the s390 back end. >> > I will be able to address the changes required for the s390 back end. > Please share the patch. Thanks. Done. There are vex and valgrind patches at https://bugs.kde.org/show_bug.cgi?id=294285 comments 9 and 10. You'll need to apply both. I have done as much as I can with them -- the x86, amd64, arm, ppc32 and ppc64 front/back ends work. s390, mips32, mips64 won't compile. To hack on this, you'll first need to re-add priv/guest_<arch>_toIR.c and priv/host_<arch>_isel.c to LIBVEX_SOURCES_COMMON in Makefile.vex.am, and you'll also need to remove the #if 0's around the relevant sections in LibVEX_Translate in VEX/priv/main_main.c. The real changes are restricted to the _toIR.c (a bit) and the _isel.c (mostly). For both MIPS and S390 I think it is pretty simple because there is (IIUC) no SIMD code generation. So the changes needed are: * in _toIR.c: any place where a dirty helper call is created, and you want to pass the baseblock pointer: - remove d->passBBP = True (since that field no long exists) - add the special value IRExprP__BBPTR as the first arg in the arg list for the call. This tells the backend to pass the baseblock pointer as the first arg * in _isel.c: - doHelperCall needs to be modified to handle IRExprP__BBPTR in arg lists - doHelperCall does not need to handle IRExprP__VECRET since we're not expecting to handle 128 or 256 bit returns on these architectures - doHelperCall needs to be modified to create and return the RetLoc value for the call; previously this was passed in to doHelperCall - see doHelperCall in host_isel_ppc.c for examples/ideas/code to copy - I suggest you add "vassert(0) // ATC" initially in all the various IRType-differentiated switches, so as to be sure all paths are verified. - I tested by running all the insn set test for each arch on Memcheck. Testing with --tool=none isn't enough since Memcheck creates calls with arg/return types that don't exist in the uninstrumented IR. Any questions, please ask. I will do the integration/committing, since that can't happen until all targets are working again. J |
|
From: Dejan J. <dej...@rt...> - 2013-08-01 11:44:19
|
On 08/01/2013 12:13 AM, Philippe Waroquiers wrote: > On Wed, 2013-07-31 at 09:13 +0200, Dejan Jevtic wrote: > >> in revision 13471 Philippe deleted include <linux/ptrace.h>. >> In getregs() and setregs() we have # ifdef PTRACE_GETREGS and I think >> that PTRACE_GETREGS is defined in <linux/ptrace.h>. Because of that >> the first part of code will not be compiled. >> In the second part of getregs and setregs we call ptrace and for >> mips the offset is in range 0,1,2...31 (not 0, 4, 8...). >> I attached a small patch that fix the second problem for mips, and >> if it's ok with you I can apply it. > I do not have access to a mips machine for the moment (gcc farm mips > systems seems down for the moment) so cannot look in depth at > the problem. > > At least on x86, amd64, PTRACE_GETREGS is defined in sys/ptrace.h. > On ppc64, PTRACE_GETREGS is not defined in sys/ptrace.h but > also not in linux/ptrace.h I checked this on gcc110 (ppc64) and I think that PTRACE_GETREGS is defined in asm/ptrace.h that is included in linux/ptrace.h > What do you find in mips sys/ptrace.h and linux/ptrace.h ? For mips PTRACE_GETREGS is defined in asm/ptrace.h that is included in linux/ptrace.h. In sys/ptrace.h for mips PTRACE_GETREGS is part of the enum. We need to include asm/ptrace.h or linux/ptrace.h if we want to preprocessor see PTRACE_GETREGS in setregs/getregs: # ifdef PTRACE_GETREGS ... # endif > (it looks better to use PTRACE_(GET/SET)REGS if possible, > as there are more chance that all needed registers are > fetched/restored than if the registers are fetched individually > with PEEKUSER. > > Otherwise, if the PEEKUSER solution must be made working on mips, > I have a few comments: > The patch is removing the sign extension > of $a0 and the "0" assignment to the "2nd register" > of the register pair (e.g. > user_mod.regs[34*2] = shared32->invoke_gdbserver; > user_mod.regs[34*2+1] = 0; > is replaced by > user_mod.regs[EF_CP0_EPC] = shared32->invoke_gdbserver; > > The sign extension and 0 assignment were added after a discussion > with Petar as otherwise a vgdb compiled in 32 bits was not working > on a 64 bits arch. > Isn't it better to keep these assignments ? For now we are trying for fix all the tests only for mips32/32bit os and mips64/64bit os. Valgrind for mips can't be compiled in dual arch for now. > (if valgrind is compiled in dual arch, then vgdb is a 64 bits > application). > > > 2nd question: looking (on the net) the user.h, it seems there > are some other registers e.g. EF_LO and EF_HI, and some others > following EF_CP0_EPC. > Shouldn't these registers also be saved and restored via PEEKUSER ? From invoke_gdbserver() I see that we are getting all registers with getregs(), modify only some of them, and then with setregs() we are writing these new values back. With PTRACE_PEEKUSER we are getting only one single registers, and I thought that would be better only to get some of the registers that we need to modify, because with PTRACE_POKEUSER we are writing back only one register at the time. Am I missing something? > It is not clear to me why the current code which should peek/poke > the full "regs" structure is not ok ? When we are using ptrace() syscall with PTRACE_PEEKUSER/PTRACE_POKEUSER mips kernel is expecting that the offset will be the number of register that need to be return as a return value. You can find more details on (search for the PTRACE_PEEKUSR/PTRACE_POKEUSR): http://lxr.free-electrons.com/source/arch/mips/kernel/ptrace.c > i.e. in asm-mips/user.h: > struct user { > unsigned long regs[EF_SIZE/4+64]; /* integer and fp regs */ > > (I have an almost zero knowledge of mips and no access to a mips > system, so the above might just be rubbish comments). > > Would be better in any case to validate the changes > using the combinations vgdb32 on 32bits os > vgdb32 on 64bits os > (so valgrind compiled single arch 32 bits) > vgdb64 debugging a 32 and 64 bits executable > > Thanks > > Philippe > > > > Regards, Dejan |