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
(9) |
2
(13) |
3
(3) |
4
(3) |
5
(4) |
|
6
(2) |
7
(4) |
8
(3) |
9
(2) |
10
|
11
|
12
(6) |
|
13
(6) |
14
(1) |
15
(2) |
16
(2) |
17
(2) |
18
|
19
|
|
20
|
21
|
22
(1) |
23
|
24
(2) |
25
(5) |
26
|
|
27
(1) |
28
(8) |
29
(3) |
30
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 22:28:46
|
On Wed, 2003-04-02 at 05:33, Adam Gundy wrote: > >Can you look at separating your patch into logically distinct pieces > (ie, signal handling, clone handling, PE parsing, XLAT, etc) rather > than one big lump patch? Then could you look at > <http://www.goop.org/~jeremy/valgrind/>http://www.goop.org/~jeremy/valgrind/ and see where there's overlap. It seem to me that <http://www.goop.org/%7Ejeremy/valgrind/77-sigcontext.patch>77-sigcontext is a dup of a lot of your signal handling stuff<http://www.goop.org/%7Ejeremy/valgrind/44-symbolic-addr.patch>. > > > looks like 77-sigcontext is providing the siginfo_t and ucontext_t arguments to signal handlers > which ask for them - unfortunately, WINE uses the older deprecated (but still documented & valid) > method of declaring a signal handler as "int handler( int signo, sigcontext_t context )" so that > it can access the sigcontext_t directly off the stack. It looks like both patches need combining. Looks like 77-sigcontext implements the sigcontext argument for the non-siginfo case as well (the chunk at +1078, vg_push_signal_frame). Is the other part of your signal patch is making SIGCONT and SIGSTOP work on threads? Anything else signal related? > > I also think that splitting the DOS/PE parsing stuff into a separate > file would be a good idea (like > <http://www.goop.org/%7Ejeremy/valgrind/44-symbolic-addr.patch>44-symbolic-addr does with stabs vs DWARF). I definitely think you should have completely separate code for handing PE vs ELF, > > > good idea - but I'd like to have a patch that WINE developers can easily apply to a valgrind CVS > checkout - giving a list of "get valgrind CVS, then apply this patch, then this patch, then..." isn't > going to get many users. Is your patch likely to hit CVS soon? Well, I need to finish the DWARF support before symbolic-addr is really ready to go in, but the object file handling refactoring could be brought out into a separate patch. > The only way to identify the PE file as it is mapped is to find the header which is mapped RO, then figure > out where the rest of the code will be mapped to. This is mainly down to Window's ability to map > files from non-page aligned offsets - multiple sections of the PE file have to be copied by WINE into > the correct bit of memory rather than mmapped (and they can't be identified at this point because there > is no identifiable header in the sections). Urg. I wonder if a better solution might be to add some more VALGRIND_* client callbacks so that the client app can tell Valgrind what's doing on in cases like this, rather than trying to teach Valgrind about every obscure dynamic loading technique. Are you reading symbolic information out of PE files? J |
|
From: Julian S. <js...@ac...> - 2003-04-02 20:14:33
|
Thx. Any enthusiasm for doing __builtin_new, __builtin_vec_new, realloc (all obvious) and calloc (no obvious corresponding fix ...) ? When I gather up a bit more steam I might do the others. J On Wednesday 02 April 2003 8:42 am, Jeremy Fitzhardinge wrote: > This patch fixes the alignment of allocated memory when running under > Valgrind but on the real CPU (for example, when you use --stop-after). > > > http://www.goop.org/~jeremy/valgrind/87-malloc-align.patch > > coregrind/vg_clientfuncs.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletion(-) > > diff -puN coregrind/vg_clientfuncs.c~87-malloc-align > coregrind/vg_clientfuncs.c --- > valgrind/coregrind/vg_clientfuncs.c~87-malloc-align Sat Mar 15 19:02:57 > 2003 +++ valgrind-jeremy/coregrind/vg_clientfuncs.c Sat Mar 15 19:02:57 > 2003 @@ -102,7 +102,11 @@ void* malloc ( Int n ) > if (VG_(running_on_simd_CPU)) { > v = (void*)SIMPLE_REQUEST1(VG_USERREQ__MALLOC, n); > } else { > - v = VG_(arena_malloc)(VG_AR_CLIENT, n); > + if (VG_(clo_alignment) == 4) > + v = VG_(arena_malloc)(VG_AR_CLIENT, n); > + else > + v = VG_(arena_malloc_aligned)(VG_AR_CLIENT, > + VG_(clo_alignment), n); > } > } > if (VG_(clo_trace_malloc)) > > _ |
|
From: Julian S. <js...@ac...> - 2003-04-02 20:11:18
|
Committed. Thanks.
J
On Wednesday 02 April 2003 4:28 pm, Adam Gundy wrote:
> the following small patch adds support for the (ancient and horrible)
> XLAT instruction. Microsoft in their infinite wisdom use it in their OLE
> dispatch code...
>
> Index: coregrind/vg_to_ucode.c
> ===================================================================
> RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_to_ucode.c,v
> retrieving revision 1.50
> diff -u -r1.50 vg_to_ucode.c
> --- coregrind/vg_to_ucode.c 3 Feb 2003 11:25:34 -0000 1.50
> +++ coregrind/vg_to_ucode.c 24 Mar 2003 14:56:09 -0000
> @@ -4299,6 +4299,25 @@
> codegen_xchg_eAX_Reg ( cb, sz, opc - 0x90 );
> break;
>
> + /* ------------------------ XLAT ----------------------- */
> +
> + case 0xD7: /* XLAT */
> + t1 = newTemp(cb); t2 = newTemp(cb);
> + uInstr2(cb, GET, sz, ArchReg, R_EBX, TempReg, t1); /* get eBX */
> + handleSegOverride( cb, sorb, t1 ); /* make t1 DS:eBX
> */ + uInstr2(cb, GET, 1, ArchReg, R_AL, TempReg, t2); /* get AL */ +
> /* Widen %AL to 32 bits, so it's all defined when we add it. */ +
> uInstr1(cb, WIDEN, 4, TempReg, t2);
> + LAST_UINSTR(cb).extra4b = 1;
> + LAST_UINSTR(cb).signed_widen = False;
> + uInstr2(cb, ADD, sz, TempReg, t2, TempReg, t1); /* add AL to eBX
> */ + uInstr2(cb, LOAD, 1, TempReg, t1, TempReg, t2); /* get byte at
> t1 into t2 */ + uInstr2(cb, PUT, 1, TempReg, t2, ArchReg, R_AL); /*
> put byte into AL */ +
> + if (dis)
> + VG_(printf)("xlat%c [ebx]\n", nameISize(sz));
> + break;
> +
> /* ------------------------ (Grp1 extensions) ---------- */
>
> case 0x80: /* Grp1 Ib,Eb */
>
>
>
> Seeya,
> Adam
|
|
From: Julian S. <js...@ac...> - 2003-04-02 19:48:19
|
> Now, I notice that in fact my 0x6E is wrong, because the else { } bit
> generates MMX2_RegRd when it should generate MMX2_MemRd.
Duh ... engage brain ...
In fact it's OK, if somewhat longwinded. It gets the address into an
integer register, does a 4-byte load into an int reg, and then moves
that into MMX land with MMX2_RegRd.
So I guess a complete 0x7E implementation can be made by inverting
data flow direction for 0x6E.
J
|
|
From: Jeremy F. <je...@go...> - 2003-04-02 19:46:23
|
On Wed, 2003-04-02 at 11:42, Julian Seward wrote:
> Um, that don't look right. [well, actually it might work if the
> dest is memory, but not if it's an ireg.]
> MOVD can't be done the same way as MOVQ.
> Compare the code for 0x6E ( mmxreg := ireg-or-mem )
> against that for 0x6F ( mmxreg := mmxreg-or-mem ).
Right you are. I misread the spec on what the instruction does. I'll
give it another go.
J
|
|
From: Julian S. <js...@ac...> - 2003-04-02 19:34:12
|
Um, that don't look right. [well, actually it might work if the
dest is memory, but not if it's an ireg.]
MOVD can't be done the same way as MOVQ.
Compare the code for 0x6E ( mmxreg := ireg-or-mem )
against that for 0x6F ( mmxreg := mmxreg-or-mem ).
0x6E generates MMX2_RegRd or MMX2_MemRd.
0x6F generates MMX2 or MMX2_MemRd.
where MMX2_RegRd is for ireg->mmxreg moves
MMX2_MemRd is for mem ->mmxreg moves
MMX2 is for purely internal MMX activity
Now, I notice that in fact my 0x6E is wrong, because the else { } bit
generates MMX2_RegRd when it should generate MMX2_MemRd.
Modulo that correction, I think 0x7F should be done same as 0x6F,
except with the direction of data flow reversed, and generating
MMX2_RegWr or MMX2_MemWr. MMX2_RegWr is problematic since I
haven't written any handlers for it, although the code for it should
be a straight rip of all the MMX2_RegRd cases.
J
On Wednesday 02 April 2003 8:39 am, Jeremy Fitzhardinge wrote:
> I tried out Mesa software rendering; it failed because V was missing
> movd reg, r/m. The fix is simple:
> (http://www.goop.org/~jeremy/valgrind/88-mmxfix.patch)
>
>
> Implement movd mm, r/m
>
>
> coregrind/vg_to_ucode.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff -puN coregrind/vg_to_ucode.c~88-mmxfix coregrind/vg_to_ucode.c
> --- valgrind/coregrind/vg_to_ucode.c~88-mmxfix Tue Apr 1 18:47:14 2003
> +++ valgrind-jeremy/coregrind/vg_to_ucode.c Tue Apr 1 19:08:04 2003
> @@ -4867,6 +4867,7 @@ static Addr disInstr ( UCodeBlock* cb, A
> }
> break;
>
> + case 0x7E: /* MOVD (src)mmxreg, (dst)mmxreg-or-mem */
> case 0x7F: /* MOVQ (src)mmxreg, (dst)mmxreg-or-mem */
> vg_assert(sz == 4);
> modrm = getUChar(eip);
> @@ -4882,7 +4883,8 @@ static Addr disInstr ( UCodeBlock* cb, A
> (((UShort)(opc)) << 8) | ((UShort)modrm),
> TempReg, tmpa);
> if (dis)
> - VG_(printf)("movq %s, %s\n",
> + VG_(printf)("mov%c %s, %s\n",
> + opc == 0x7e ? 'd' : 'q',
> nameMMXReg(gregOfRM(modrm)),
> dis_buf);
> }
> @@ -5022,9 +5024,9 @@ static Addr disInstr ( UCodeBlock* cb, A
> unimp2:
> VG_(printf)("disInstr: unhandled 2-byte opcode: "
> "0x%x 0x%x 0x%x\n",
> + (Int)getUChar(eip-2),
> (Int)getUChar(eip-1),
> - (Int)getUChar(eip+0),
> - (Int)getUChar(eip+1) );
> + (Int)getUChar(eip-0) );
>
> VG_(printf)("This _might_ be the result of executing a "
> "SSE, SSE2 or 3DNow!\n" );
>
> _
|
|
From: Adam G. <ar...@cy...> - 2003-04-02 16:30:07
|
the following small patch adds support for the (ancient and horrible)
XLAT instruction. Microsoft in their infinite wisdom use it in their OLE
dispatch code...
Index: coregrind/vg_to_ucode.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_to_ucode.c,v
retrieving revision 1.50
diff -u -r1.50 vg_to_ucode.c
--- coregrind/vg_to_ucode.c 3 Feb 2003 11:25:34 -0000 1.50
+++ coregrind/vg_to_ucode.c 24 Mar 2003 14:56:09 -0000
@@ -4299,6 +4299,25 @@
codegen_xchg_eAX_Reg ( cb, sz, opc - 0x90 );
break;
+ /* ------------------------ XLAT ----------------------- */
+
+ case 0xD7: /* XLAT */
+ t1 = newTemp(cb); t2 = newTemp(cb);
+ uInstr2(cb, GET, sz, ArchReg, R_EBX, TempReg, t1); /* get eBX */
+ handleSegOverride( cb, sorb, t1 ); /* make t1 DS:eBX */
+ uInstr2(cb, GET, 1, ArchReg, R_AL, TempReg, t2); /* get AL */
+ /* Widen %AL to 32 bits, so it's all defined when we add it. */
+ uInstr1(cb, WIDEN, 4, TempReg, t2);
+ LAST_UINSTR(cb).extra4b = 1;
+ LAST_UINSTR(cb).signed_widen = False;
+ uInstr2(cb, ADD, sz, TempReg, t2, TempReg, t1); /* add AL to eBX */
+ uInstr2(cb, LOAD, 1, TempReg, t1, TempReg, t2); /* get byte at t1 into t2 */
+ uInstr2(cb, PUT, 1, TempReg, t2, ArchReg, R_AL); /* put byte into AL */
+
+ if (dis)
+ VG_(printf)("xlat%c [ebx]\n", nameISize(sz));
+ break;
+
/* ------------------------ (Grp1 extensions) ---------- */
case 0x80: /* Grp1 Ib,Eb */
Seeya,
Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.
|
|
From: Adam G. <ar...@cy...> - 2003-04-02 13:34:21
|
At 16:51 01/04/03 -0800, you wrote: >On Tue, 2003-04-01 at 15:09, Julian Seward wrote: >>Just to let you know your patch is under consideration. Thanks for it, >>looks like a lot of work, and useful. I'll try and get back to you >>on it in a few days, but we're (me, at least) are just overloaded and >>haven't had time to look at it properly yet. >Hm. It looks like this patch will clash a lot with the work I've been doing on making UML work well, and the work on extracting symtab info from various file formats. There's a lot of different things in there: some are clearly generically OK (XLAT), others need a good hard looking at to see whether they're Wine-specific or are generally OK (signal and clone handing) and others are purely Wine-specific (PE handling). With the Wine-specific things, I wonder if we need to look at refactoring the object file handing a bit to make it easier to plug in different object file handlers. the only *really* WINE specific stuff is the PE/PDB handling. The rest is generic - clone(), signals, better handling of threads which switch stacks, and XLAT. >Adam: > >Can you look at separating your patch into logically distinct pieces (ie, signal handling, clone handling, PE parsing, XLAT, etc) rather than one big lump patch? Then could you look at <http://www.goop.org/~jeremy/valgrind/>http://www.goop.org/~jeremy/valgrind/ and see where there's overlap. It seem to me that <http://www.goop.org/%7Ejeremy/valgrind/77-sigcontext.patch>77-sigcontext is a dup of a lot of your signal handling stuff<http://www.goop.org/%7Ejeremy/valgrind/44-symbolic-addr.patch>. looks like 77-sigcontext is providing the siginfo_t and ucontext_t arguments to signal handlers which ask for them - unfortunately, WINE uses the older deprecated (but still documented & valid) method of declaring a signal handler as "int handler( int signo, sigcontext_t context )" so that it can access the sigcontext_t directly off the stack. It looks like both patches need combining. > I also think that splitting the DOS/PE parsing stuff into a separate file would be a good idea (like <http://www.goop.org/%7Ejeremy/valgrind/44-symbolic-addr.patch>44-symbolic-addr does with stabs vs DWARF). I definitely think you should have completely separate code for handing PE vs ELF, good idea - but I'd like to have a patch that WINE developers can easily apply to a valgrind CVS checkout - giving a list of "get valgrind CVS, then apply this patch, then this patch, then..." isn't going to get many users. Is your patch likely to hit CVS soon? > even if there are similarities in the file formats. You might also want to look at <http://www.goop.org/%7Ejeremy/valgrind/70-exe-dataseg.patch>70-exe-dataseg regarding the discrimination of code-bearing mappings from non-code-bearing mappings. not sure why this is needed - the code in vg_symtab.c already checks the signatures of the sections it examines (ELF, PE etc etc). >I'm also curious about this change to mmap_segment: > static >-void mmap_segment ( Addr a, UInt len, UInt prot, Int fd ) >+void mmap_segment ( Addr a, UInt len, UInt prot, UInt flags, Int fd, Int Offset ) > { > Bool rr, ww, xx; > > /* Records segment, reads debug symbols if necessary */ >- if ((prot & PROT_EXEC) && fd != -1) >+ if ((((prot & (PROT_EXEC|PROT_WRITE)) == PROT_EXEC) || /* native */ >+ (((prot & (PROT_READ|PROT_WRITE)) == PROT_READ) && >+ (flags & MAP_PRIVATE) && >+ (Offset == 0))) /* Windows PE? */ >+ && fd != -1) > VG_(new_exe_segment) ( a, len ); > >This seems to suggest that any private read-only (no X) mapping from offset 0 of a file could be a PE file. Is that right? Certainly a lot of other mmapings (perhaps even most) would pass the same test. I wonder if checking for a magic number or something would be useful. In fact, there seems to be a lot of reliance on looking at shared vs. private mappings to try and distinguish between ELF and PE segments: that doesn't seem like a generally safe thing to do. shared segments are always ignored by PE simply to reduce the number of potential hits. ELF & PE are distinguished by looking for magic numbers. The only way to identify the PE file as it is mapped is to find the header which is mapped RO, then figure out where the rest of the code will be mapped to. This is mainly down to Window's ability to map files from non-page aligned offsets - multiple sections of the PE file have to be copied by WINE into the correct bit of memory rather than mmapped (and they can't be identified at this point because there is no identifiable header in the sections). Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Jeremy F. <je...@go...> - 2003-04-02 09:41:06
|
On Wed, 2003-04-02 at 01:26, Madhu M. Kurup wrote:
> disInstr: unhandled 2-byte opcode: 0x7E 0xC0 0x66
That's movd. Try the patch I just posted.
J
|
|
From: Madhu M. K. <mm...@ya...> - 2003-04-02 09:31:11
|
Julian Seward wrote: > >Thanks Arnaud, dabench is also a good test. I just built it, fixed >the 2 missing insns it showed up, and so it works now. > >Madhu: one of insns I fixed is the one you tripped over in xmms. >Could you cvs update and try xmms again? Thanks. Apologies for the rather late reply. All the nice development work on valgrind happens at home :) CVS updated and recompiled. Hmm, seems like xmms will be a good test set: ==3253== pthread_mutex_unlock: mutex is not locked ==3253== at 0x4021F257: __pthread_mutex_unlock (vg_libpthread.c:977) ==3253== by 0x403119D0: gtk_main (in /usr/lib/libgtk-1.2.so.0.9.1) ==3253== ==3253== Conditional jump or move depends on uninitialised value(s) ==3253== at 0x40312533: gtk_propagate_event (in /usr/lib/libgtk-1.2.so.0.9.1) disInstr: unhandled 2-byte opcode: 0x7E 0xC0 0x66 This _might_ be the result of executing a SSE, SSE2 or 3DNow! instruction. Valgrind does not currently support such instructions. Sorry. Illegal instruction I wish I could do more than just report, but my x86 info is strictly limited ..... Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Jeremy F. <je...@go...> - 2003-04-02 08:42:36
|
This patch fixes the alignment of allocated memory when running under Valgrind but on the real CPU (for example, when you use --stop-after). http://www.goop.org/~jeremy/valgrind/87-malloc-align.patch coregrind/vg_clientfuncs.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) diff -puN coregrind/vg_clientfuncs.c~87-malloc-align coregrind/vg_clientfuncs.c --- valgrind/coregrind/vg_clientfuncs.c~87-malloc-align Sat Mar 15 19:02:57 2003 +++ valgrind-jeremy/coregrind/vg_clientfuncs.c Sat Mar 15 19:02:57 2003 @@ -102,7 +102,11 @@ void* malloc ( Int n ) if (VG_(running_on_simd_CPU)) { v = (void*)SIMPLE_REQUEST1(VG_USERREQ__MALLOC, n); } else { - v = VG_(arena_malloc)(VG_AR_CLIENT, n); + if (VG_(clo_alignment) == 4) + v = VG_(arena_malloc)(VG_AR_CLIENT, n); + else + v = VG_(arena_malloc_aligned)(VG_AR_CLIENT, + VG_(clo_alignment), n); } } if (VG_(clo_trace_malloc)) _ |
|
From: Jeremy F. <je...@go...> - 2003-04-02 08:39:55
|
I tried out Mesa software rendering; it failed because V was missing movd reg, r/m. The fix is simple: (http://www.goop.org/~jeremy/valgrind/88-mmxfix.patch) Implement movd mm, r/m coregrind/vg_to_ucode.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff -puN coregrind/vg_to_ucode.c~88-mmxfix coregrind/vg_to_ucode.c --- valgrind/coregrind/vg_to_ucode.c~88-mmxfix Tue Apr 1 18:47:14 2003 +++ valgrind-jeremy/coregrind/vg_to_ucode.c Tue Apr 1 19:08:04 2003 @@ -4867,6 +4867,7 @@ static Addr disInstr ( UCodeBlock* cb, A } break; + case 0x7E: /* MOVD (src)mmxreg, (dst)mmxreg-or-mem */ case 0x7F: /* MOVQ (src)mmxreg, (dst)mmxreg-or-mem */ vg_assert(sz == 4); modrm = getUChar(eip); @@ -4882,7 +4883,8 @@ static Addr disInstr ( UCodeBlock* cb, A (((UShort)(opc)) << 8) | ((UShort)modrm), TempReg, tmpa); if (dis) - VG_(printf)("movq %s, %s\n", + VG_(printf)("mov%c %s, %s\n", + opc == 0x7e ? 'd' : 'q', nameMMXReg(gregOfRM(modrm)), dis_buf); } @@ -5022,9 +5024,9 @@ static Addr disInstr ( UCodeBlock* cb, A unimp2: VG_(printf)("disInstr: unhandled 2-byte opcode: " "0x%x 0x%x 0x%x\n", + (Int)getUChar(eip-2), (Int)getUChar(eip-1), - (Int)getUChar(eip+0), - (Int)getUChar(eip+1) ); + (Int)getUChar(eip-0) ); VG_(printf)("This _might_ be the result of executing a " "SSE, SSE2 or 3DNow!\n" ); _ |
|
From: Jeremy F. <je...@go...> - 2003-04-02 00:54:01
|
On Tue, 2003-04-01 at 15:09, Julian Seward wrote: > Just to let you know your patch is under consideration. Thanks for > it, > looks like a lot of work, and useful. I'll try and get back to you > on it in a few days, but we're (me, at least) are just overloaded and > haven't had time to look at it properly yet. Hm. It looks like this patch will clash a lot with the work I've been doing on making UML work well, and the work on extracting symtab info from various file formats. There's a lot of different things in there: some are clearly generically OK (XLAT), others need a good hard looking at to see whether they're Wine-specific or are generally OK (signal and clone handing) and others are purely Wine-specific (PE handling). With the Wine-specific things, I wonder if we need to look at refactoring the object file handing a bit to make it easier to plug in different object file handlers. Adam: Can you look at separating your patch into logically distinct pieces (ie, signal handling, clone handling, PE parsing, XLAT, etc) rather than one big lump patch? Then could you look at http://www.goop.org/~jeremy/valgrind/ and see where there's overlap. It seem to me that 77-sigcontext is a dup of a lot of your signal handling stuff. I also think that splitting the DOS/PE parsing stuff into a separate file would be a good idea (like 44-symbolic-addr does with stabs vs DWARF). I definitely think you should have completely separate code for handing PE vs ELF, even if there are similarities in the file formats. You might also want to look at 70-exe-dataseg regarding the discrimination of code-bearing mappings from non-code-bearing mappings. I'm also curious about this change to mmap_segment: static -void mmap_segment ( Addr a, UInt len, UInt prot, Int fd ) +void mmap_segment ( Addr a, UInt len, UInt prot, UInt flags, Int fd, Int Offset ) { Bool rr, ww, xx; /* Records segment, reads debug symbols if necessary */ - if ((prot & PROT_EXEC) && fd != -1) + if ((((prot & (PROT_EXEC|PROT_WRITE)) == PROT_EXEC) || /* native */ + (((prot & (PROT_READ|PROT_WRITE)) == PROT_READ) && + (flags & MAP_PRIVATE) && + (Offset == 0))) /* Windows PE? */ + && fd != -1) VG_(new_exe_segment) ( a, len ); This seems to suggest that any private read-only (no X) mapping from offset 0 of a file could be a PE file. Is that right? Certainly a lot of other mmapings (perhaps even most) would pass the same test. I wonder if checking for a magic number or something would be useful. In fact, there seems to be a lot of reliance on looking at shared vs. private mappings to try and distinguish between ELF and PE segments: that doesn't seem like a generally safe thing to do. Thanks, J |