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: Julian S. <js...@ac...> - 2003-04-05 22:02:41
|
> Hmm. I did, but compiled and built only one directory :) > > And the news: it worked. Performance was sucky, but hey, you cant > expect too much from a profiling xmms - I tried the OpenGL visualization > plugin as well - no problems. Cool! > Incidentally, if you want to start the 3dNow set, here's what it reported > for that: Er, no thanks. I'm not doing 3DNow; MMX, SSE and SSE2 are more than enough complication for me. I'm looking hard at SSE/SSE2 now and promised myself I would start hacking on it this weekend, but it hasn't happened yet :-) J |
|
From: Madhu M. K. <mm...@ya...> - 2003-04-05 21:48:15
|
Julian Seward wrote: > >Did your cvs up pick up a new version of memcheck/mc_translate.c? >You need rev 1.19 and it looks like you only have rev 1.18. >I definitely committed it. Hmm. I did, but compiled and built only one directory :) And the news: it worked. Performance was sucky, but hey, you cant expect too much from a profiling xmms - I tried the OpenGL visualization plugin as well - no problems. Incidentally, if you want to start the 3dNow set, here's what it reported for that: -- disInstr: unhandled 2-byte opcode: 0xE 0xF 0x6F This _might_ be the result of executing a SSE, SSE2 or 3DNow! instruction. Valgrind does not currently support such instructions. Sorry. Illegal instruction -- The plugin also has the ability to automatically detect what your CPU is (3dnow, MMX, std) and run, I tried that option as well - and it seemed to work. I am not sure if it picked up MMX or just defaulted back to std when it did that, but the detection portion of the xmms code didn't cause any gotchas. Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Julian S. <js...@ac...> - 2003-04-05 09:22:53
|
Did your cvs up pick up a new version of memcheck/mc_translate.c? You need rev 1.19 and it looks like you only have rev 1.18. I definitely committed it. J > Did so, resulting in this: > > --- > ==3423== pthread_mutex_unlock: mutex is not locked > ==3423== at 0x4021F257: __pthread_mutex_unlock (vg_libpthread.c:977) > ==3423== by 0x403119D0: gtk_main (in /usr/lib/libgtk-1.2.so.0.9.1) > > Memcheck: the `impossible' happened: > I don't know how to instrument MMX2_RegWr (yet) > Basic block ctr is approximately 35900000 > > sched status: > > Thread 1: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 > ==3423== at 0x40222051: my_do_syscall2 (vg_libpthread.c:2380) > ==3423== by 0x40222667: vgIntercept_poll (vg_libpthread.c:2675) > ==3423== by 0x40182DB0: __poll (vg_intercept.c:198) > ==3423== by 0x4040C7E3: (within /usr/lib/libglib-1.2.so.0.0.10) > > Thread 2: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 > ==3423== at 0x40222051: my_do_syscall2 (vg_libpthread.c:2380) > ==3423== by 0x402223E4: vgIntercept_select (vg_libpthread.c:2566) > ==3423== by 0x40182E36: __select (vg_intercept.c:247) > ==3423== by 0x8068AF9: ctrlsocket_func (controlsocket.c:205) > > Thread 3: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 > ==3423== at 0x405E1581: __libc_nanosleep (in /lib/libc-2.2.4.so) > ==3423== by 0x4026EA61: xmms_usleep (util.c:105) > ==3423== by 0x8067124: playlist_get_info_func (playlist.c:1621) > ==3423== by 0x4021EA2B: thread_wrapper (vg_libpthread.c:671) > > Thread 4: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==3423== at 0x422082B7: (within > /home/mmk/dev/xmms/lib/xmms/Input/libmpg123.so) > > Thread 5: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==3423== at 0x4021E990: thread_wrapper (vg_libpthread.c:638) > > Please report this bug to: js...@ac... > --- > > Cheerio, > M > > Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Madhu M. K. <mm...@ya...> - 2003-04-05 08:51:28
|
Julian Seward wrote: > >Madhu; cvs up and try again? A fix for 0x7E is finally in the repo. > Did so, resulting in this: --- ==3423== pthread_mutex_unlock: mutex is not locked ==3423== at 0x4021F257: __pthread_mutex_unlock (vg_libpthread.c:977) ==3423== by 0x403119D0: gtk_main (in /usr/lib/libgtk-1.2.so.0.9.1) Memcheck: the `impossible' happened: I don't know how to instrument MMX2_RegWr (yet) Basic block ctr is approximately 35900000 sched status: Thread 1: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 ==3423== at 0x40222051: my_do_syscall2 (vg_libpthread.c:2380) ==3423== by 0x40222667: vgIntercept_poll (vg_libpthread.c:2675) ==3423== by 0x40182DB0: __poll (vg_intercept.c:198) ==3423== by 0x4040C7E3: (within /usr/lib/libglib-1.2.so.0.0.10) Thread 2: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 ==3423== at 0x40222051: my_do_syscall2 (vg_libpthread.c:2380) ==3423== by 0x402223E4: vgIntercept_select (vg_libpthread.c:2566) ==3423== by 0x40182E36: __select (vg_intercept.c:247) ==3423== by 0x8068AF9: ctrlsocket_func (controlsocket.c:205) Thread 3: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 ==3423== at 0x405E1581: __libc_nanosleep (in /lib/libc-2.2.4.so) ==3423== by 0x4026EA61: xmms_usleep (util.c:105) ==3423== by 0x8067124: playlist_get_info_func (playlist.c:1621) ==3423== by 0x4021EA2B: thread_wrapper (vg_libpthread.c:671) Thread 4: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==3423== at 0x422082B7: (within /home/mmk/dev/xmms/lib/xmms/Input/libmpg123.so) Thread 5: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==3423== at 0x4021E990: thread_wrapper (vg_libpthread.c:638) Please report this bug to: js...@ac... --- Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Julian S. <js...@ac...> - 2003-04-04 20:45:17
|
On Friday 04 April 2003 8:18 pm, Jeremy Fitzhardinge wrote: > I have some code which can use SSE/3dnow instructions. To avoid that, I > use valgrind/valgrind.h's RUNNING_ON_VALGRIND macro. There are no skin > annotations. What's wrong with that? Um, I'm not sure, but various people got snafu'd using valgrind.h in 1.9.X when we silently changed the relevant thing to memcheck.h. When they changed to memcheck.h, everything "just worked again". So I figured I'd make valgrind.h unusable on its own. > BTW, its #warn, not #warning. gcc didn't yelp about #warning when I tested, so is #warning OK or not? J |
|
From: Julian S. <js...@ac...> - 2003-04-04 20:42:44
|
Madhu; cvs up and try again? A fix for 0x7E is finally in the repo. Thx J > ==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 > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Jeremy F. <je...@go...> - 2003-04-04 20:20:10
|
I have some code which can use SSE/3dnow instructions. To avoid that, I
use valgrind/valgrind.h's RUNNING_ON_VALGRIND macro. There are no skin
annotations. What's wrong with that?
BTW, its #warn, not #warning.
J
|
|
From: Adam G. <ar...@cy...> - 2003-04-03 14:20:08
|
patch which adds support for the new gettid() system call, and makes
the new set_thread_area() system call return ENOSYS (currently anything
using this system call should cope with it not existing and fall back to
modify_ldt()).
Index: coregrind/vg_syscalls.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.25
diff -u -r1.25 vg_syscalls.c
--- coregrind/vg_syscalls.c 24 Feb 2003 21:55:34 -0000 1.25
+++ coregrind/vg_syscalls.c 3 Apr 2003 14:11:23 -0000
@@ -30,11 +30,19 @@
*/
#include "vg_include.h"
+#include <errno.h>
/* vg_unsafe.h should NOT be included into any file except this
one. */
#include "vg_unsafe.h"
+#ifndef __NR_set_thread_area
+#define __NR_set_thread_area 243
+#endif
+
+#ifndef __NR_gettid
+#define __NR_gettid 224
+#endif
/* All system calls are channelled through here, doing two things:
@@ -598,6 +610,14 @@
break;
# endif
+# if defined(__NR_set_thread_area)
+ case __NR_set_thread_area:
+ /* set_thread_area() */
+ MAYBE_PRINTF("set_thread_area ( )\n");
+ SET_EAX(tid, -ENOSYS);
+ break;
+# endif
+
# if defined(__NR_modify_ldt)
case __NR_modify_ldt: /* syscall 123 */
/* int modify_ldt(int func, void *ptr,
@@ -647,6 +667,14 @@
break;
# endif
+# if defined(__NR_gettid)
+ case __NR_gettid: /* syscall 224 */
+ /* pid_t gettid(void); */
+ MAYBE_PRINTF("gettid ()\n");
+ KERNEL_DO_SYSCALL(tid,res);
+ break;
+# endif
+
# if defined(__NR_setxattr)
case __NR_setxattr: /* syscall 226 */
/* int setxattr (const char *path, const char *name,
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-03 00:50:29
|
On Wed, 2003-04-02 at 11:56, Julian Seward wrote:
> > 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.
OK, have a look at 88-mmxfix now.
J
|
|
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 |
|
From: Julian S. <js...@ac...> - 2003-04-01 23:24:56
|
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. J On Monday 31 March 2003 1:53 pm, Arnaud Desitter wrote: > Hi, > > That's all excellent news. Another small self-contained code is > Wolfgang Suttrop's data acquisition benchmark > (http://www.ipp.mpg.de/~Wolfgang.Suttrop/daq/dabench/) > It builds easily and triggers a valgrind fault: > > <quote> > disInstr: unhandled 2-byte opcode: 0x71 0xF0 0x4 > This _might_ be the result of executing a SSE, SSE2 or 3DNow! > instruction. Valgrind does not currently support such instructions. > Sorry. </quote> > > I haven't found that many freely available codes that use MMX > instructions except within large libraries such as gmp. However, > using gcc 3.2's "mmintrin.h", it shouldn't be too difficult to write > some test cases. > > Regards, > > > ----- Original Message ----- > From: "Julian Seward" <js...@ac...> > To: "Arnaud Desitter" <arn...@ge...>; > <val...@li...> > Sent: Sunday, March 30, 2003 12:31 PM > Subject: Re: [Valgrind-developers] Re: [Valgrind-users] Need testers for > MMX support > > > Yes, irred was a good test case, and shook out various bugs and > > missing insns. I now believe the head should run most MMX code OK, > > and I've taught the memcheck (default) skin how to instrument MMX > > code, so "valgrind ./my_mmx_program" should work. > > > > J > > > > On Thursday 27 March 2003 11:59 am, Arnaud Desitter wrote: > > > Hi, > > > > > > I do not have much time as the moment to test it myself > > > but Richard Brent's irred should be a good test case, small > > > and simple. > > > http://web.comlab.ox.ac.uk/oucl/work/richard.brent/irred.html > > > > > > Regards, > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2003-04-01 23:01:24
|
Hi, 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. J I had a look over the patch just now. > is there any chance of this patch getting into the CVS repository? most of > the changes are actually bug fixes to valgrind (mostly its threading > support and signal handling, plus a translation for the XLAT instruction). > > the only "extra" code is the support for the PE/PDB file formats, which is > pretty much restricted to vg_symtab.c > > comments? bug reports? > > > Seeya, > Adam |
|
From: Julian S. <js...@ac...> - 2003-04-01 17:53:37
|
> On running the beast ; with both (3DNow and MMX) switched off, the
> program ran fine; with only MMX I get the following:
>
> ==31255== pthread_mutex_unlock: mutex is not locked
> ==31255== at 0x4021E257: __pthread_mutex_unlock (vg_libpthread.c:977)
> ==31255== by 0x8085A78: playlistwin_update_sinfo (playlistwin.c:191)
> ==31255== by 0x805BC70: load_skin (skin.c:649)
> ==31255== by 0x807DDE1: main (main.c:3466)
> ==31255==
> ==31255== pthread_mutex_unlock: mutex is not locked
> ==31255== at 0x4021E257: __pthread_mutex_unlock (vg_libpthread.c:977)
> ==31255== by 0x403109D0: gtk_main (in /usr/lib/libgtk-1.2.so.0.9.1)
> disInstr: unhandled 2-byte opcode: 0x72 0xE0 0xD
> This _might_ be the result of executing a SSE, SSE2 or 3DNow!
> instruction. Valgrind does not currently support such instructions.
> Sorry.
> Illegal instruction
>
> With 3dNow (no great surprise)
> ==31300== Conditional jump or move depends on uninitialised value(s)
> ==31300== at 0x4031B506: (within /usr/lib/libgtk-1.2.so.0.9.1)
> ==31300== by 0x42AD740B: ???
> disInstr: unhandled 2-byte opcode: 0xE 0xF 0x6F
> This _might_ be the result of executing a SSE, SSE2 or 3DNow!
> instruction. Valgrind does not currently support such instructions.
> Sorry.
> Illegal instruction
>
> I will continually track CVS head and report the status of MMX
> support in xmms .....
Ha. That's a very useful thing to do. Thanks.
Can you try the attached patch and let me know if it helps?
J
sewardj@phoenix:~/VgHEAD/valgrind$ cvs diff -rHEAD coregrind/vg_to_ucode.c
Index: coregrind/vg_to_ucode.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_to_ucode.c,v
retrieving revision 1.54
diff -u -3 -p -r1.54 vg_to_ucode.c
--- coregrind/vg_to_ucode.c 27 Mar 2003 23:52:58 -0000 1.54
+++ coregrind/vg_to_ucode.c 1 Apr 2003 17:50:28 -0000
@@ -4771,7 +4771,8 @@ static Addr disInstr ( UCodeBlock* cb, A
}
break;
- case 0x73: /* PSLL/PSRA/PSRL mmxreg by imm8 */
+ case 0x72: case 0x73:
+ /* PSLL/PSRA/PSRL mmxreg by imm8 */
{
UChar byte1, byte2, byte3, subopc, mmxreg;
vg_assert(sz == 4);
|