You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(1) |
3
|
|
4
|
5
|
6
|
7
(10) |
8
(6) |
9
(2) |
10
|
|
11
|
12
(3) |
13
(9) |
14
(10) |
15
(2) |
16
(1) |
17
|
|
18
(1) |
19
(2) |
20
(7) |
21
(2) |
22
(7) |
23
(11) |
24
(5) |
|
25
(3) |
26
(8) |
27
(7) |
28
(8) |
29
|
30
(1) |
|
|
From: Paul H. <pa...@ha...> - 2007-11-13 23:25:48
|
On Nov 13, 2007 5:37 PM, John Reiser <jr...@bi...> wrote: > > Q. Is there an ARM port of Valgrind? > > > > A. No. ... part of the license agreement for accessing the > > architecture specifications (which would be a necessity for porting > > Valgrind and VEX to ARM) is that you do not attempt to develop models > > of microprocessor cores based on ARM. ... > > > Valgrind is essentially a CPU model, so this clause would seem to > > rule out any further development. ARM is known to enforce this > > license requirement vigorously. > > On the other hand, it would be a worthy semester project to reverse > engineer that part of the ARM architecture that is compiled by gcc > and supported by glibc. Grab an NSLU2, install Debian Linux and gcc and gdb. > Build many small programs, single step them, observe what happens, > document. That would be enough for a large majority of user programs, > and it would not be encumbered by any agreement with ARM. QEMU supports ARM and is released under the GPL. So all of the pieces are compatible with the GPL, and therefore with Valgrind. http://fabrice.bellard.free.fr/qemu/license.html Not only can a programmer look at the source to QEMU, they can ask the QEMU developers questions. If you google for valgrind arm qemu, you find http://fabrice.bellard.free.fr/qemu/qemu-tech.html Which says: ---cut here--- Like Valgrind [2], QEMU does user space emulation and dynamic translation. Valgrind is mainly a memory debugger while QEMU has no support for it (QEMU could be used to detect out of bound memory accesses as Valgrind, but it has no support to track uninitialised data as Valgrind does). The Valgrind dynamic translator generates better code than QEMU (in particular it does register allocation) but it is closely tied to an x86 host and target and has no support for precise exceptions and system emulation. ---cut here--- Am I missing anything? I mean in terms of legal theory, obviously, there is the significant issue of finding volunteers with the skills and expertise to add ARM support to Valgrind. And the volunteers can't have been tainted by looking at any of the forbidden ARM documentation. -- Paul Haas |
|
From: Robert W. <rj...@du...> - 2007-11-13 23:14:23
|
I understand that's usually how these things are done. IANAL, so no idea exactly how legal that is. ARM may not have a case if you try this, but they could still make you pay for a lawyer. On Nov 13, 2007, at 2:37 PM, John Reiser wrote: >> Q. Is there an ARM port of Valgrind? >> >> A. No. ... part of the license agreement for accessing the >> architecture specifications (which would be a necessity for porting >> Valgrind and VEX to ARM) is that you do not attempt to develop models >> of microprocessor cores based on ARM. ... > >> Valgrind is essentially a CPU model, so this clause would seem to >> rule out any further development. ARM is known to enforce this >> license requirement vigorously. > > On the other hand, it would be a worthy semester project to reverse > engineer that part of the ARM architecture that is compiled by gcc > and supported by glibc. Grab an NSLU2, install Debian Linux and > gcc and gdb. > Build many small programs, single step them, observe what happens, > document. That would be enough for a large majority of user programs, > and it would not be encumbered by any agreement with ARM. > > -- > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R.
|
> Q. Is there an ARM port of Valgrind? > > A. No. ... part of the license agreement for accessing the > architecture specifications (which would be a necessity for porting > Valgrind and VEX to ARM) is that you do not attempt to develop models > of microprocessor cores based on ARM. ... > Valgrind is essentially a CPU model, so this clause would seem to > rule out any further development. ARM is known to enforce this > license requirement vigorously. On the other hand, it would be a worthy semester project to reverse engineer that part of the ARM architecture that is compiled by gcc and supported by glibc. Grab an NSLU2, install Debian Linux and gcc and gdb. Build many small programs, single step them, observe what happens, document. That would be enough for a large majority of user programs, and it would not be encumbered by any agreement with ARM. -- |
|
From: Robert W. <rj...@du...> - 2007-11-13 22:14:22
|
A quick search of the mailing list and bugzilla will show that this
is a frequently requested feature, but one that - for legal reasons -
is unlikely to happen any time soon.
Julian/Nick: perhaps we need a FAQ entry for this? Something like this:
Q. Is there an ARM port of Valgrind?
A. No. Some initial work was done for this, but has been
discontinued. ARM keeps pretty strict controls on its architecture.
For example, part of the license agreement for accessing the
architecture specifications (which would be a necessity for porting
Valgrind and VEX to ARM) is that you do not attempt to develop models
of microprocessor cores based on ARM. For example, see paragraph 2
of this ARMv7-M architecture document license agreement:
http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html
Valgrind is essentially a CPU model, so this clause would seem to
rule out any further development. ARM is known to enforce this
license requirement vigorously.
Regards,
Robert.
On Nov 13, 2007, at 1:06 AM, Gilles Marceau wrote:
> Hello,
>
> valgrind is a powerfull tool that we use very often, and we are
> very happy with it.
> It would be great if it could be also be available on the arm/linux
> platform. Is there
> any plan to add this platform in a next release ?
>
> Gilles
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Jeroen N. W. [Bahco] <jn...@xs...> - 2007-11-13 20:03:58
|
My guess is that you have to start valgrind with the option --trace-children=yes. See http://valgrind.org/docs/manual/manual-core.html#manual-core.basicopts Jeroen. Shahriyar Amini wrote: > Hi, > > I am trying to instrument the distcc daemon, however, after I start > Valgrind with distccd, Valgrind exits. What is noteworthy is that the > distccd process lives on after Valgrind exits. This gives me reason to > believe that Valgrind does not start instrumentation on it, or that the > daemon goes to sleep before Valgrind can start. Can someone elaborate on > this? Is there a way to instrument daemons? > > Thanks, > Shahriyar > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Shahriyar A. <sm...@co...> - 2007-11-13 17:51:33
|
Hi, I am trying to instrument the distcc daemon, however, after I start Valgrind with distccd, Valgrind exits. What is noteworthy is that the distccd process lives on after Valgrind exits. This gives me reason to believe that Valgrind does not start instrumentation on it, or that the daemon goes to sleep before Valgrind can start. Can someone elaborate on this? Is there a way to instrument daemons? Thanks, Shahriyar |
|
From: Aleix <ale...@gm...> - 2007-11-13 11:02:32
|
Fixed this issue for me too! :) On Nov 12, 2007 9:48 PM, Julian Seward <js...@ac...> wrote: > > > Any idea what could be causing this and what to do about it? > > The recent Helgrind merge changed a bunch of internal interfaces. > I'm pretty sure this will go away if you rebuild from clean: > make distclean (not merely clean) and start over. > > > PS: I updated in order to play with helgrind (which doesn't seem to > > have this problem). Thanks for bringing helgrind back to life! > > :-) > > J > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Gilles M. <gil...@gm...> - 2007-11-13 09:06:32
|
Hello, valgrind is a powerfull tool that we use very often, and we are very happy with it. It would be great if it could be also be available on the arm/linux platform. Is there any plan to add this platform in a next release ? Gilles |
|
From: Duncan S. <bal...@fr...> - 2007-11-13 09:03:30
|
On Monday 12 November 2007 21:48:32 Julian Seward wrote: > > > Any idea what could be causing this and what to do about it? > > The recent Helgrind merge changed a bunch of internal interfaces. > I'm pretty sure this will go away if you rebuild from clean: > make distclean (not merely clean) and start over. You were right: doing "distclean" fixed it - thanks! And thanks again for this fine tool. Best wishes, Duncan. |
|
From: Julian S. <js...@ac...> - 2007-11-12 20:49:18
|
> Any idea what could be causing this and what to do about it? The recent Helgrind merge changed a bunch of internal interfaces. I'm pretty sure this will go away if you rebuild from clean: make distclean (not merely clean) and start over. > PS: I updated in order to play with helgrind (which doesn't seem to > have this problem). Thanks for bringing helgrind back to life! :-) J |
|
From: Duncan S. <bal...@fr...> - 2007-11-12 17:00:33
|
I built valgrind from svn of a few hours ago, and ran memcheck (valgrind --tool=memcheck --db-attach=yes) on a multithreaded program. At startup I get: ==11934== Memcheck, a memory error detector. ==11934== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11934== Using LibVEX rev 1672M, a library for dynamic binary translation. ==11934== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11934== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==11934== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11934== For more details, rerun with: -v ==11934== ------ IMark(0x4000810, 2) ------ Memcheck: the 'impossible' happened: hasBogusLiterals ==11934== at 0x38017CFB: report_and_quit (m_libcassert.c:140) ==11934== by 0x38017E1D: panic (m_libcassert.c:210) ==11934== by 0x38017E55: vgPlain_tool_panic (m_libcassert.c:225) ==11934== by 0x38012B35: vgMemCheck_instrument (mc_translate.c:3298) ==11934== by 0x38089EFB: LibVEX_Translate (vex_main.c:500) ==11934== by 0x3802B3D2: vgPlain_translate (m_translate.c:1417) ==11934== by 0x38034CB3: vgPlain_scheduler (scheduler.c:762) ==11934== by 0x3804AA35: run_a_thread_NORETURN (syswrap-linux.c:87) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==11934== at 0x4000810: (within /lib/ld-2.6.1.so) Any idea what could be causing this and what to do about it? Thanks, Duncan. PS: I updated in order to play with helgrind (which doesn't seem to have this problem). Thanks for bringing helgrind back to life! |
|
From: Y G. A. N. <gir...@ap...> - 2007-11-12 04:15:20
|
Thank you Nick. You seem to have answered the question earlier [1] too, I realised :) [1] http://article.gmane.org/gmane.comp.debugging.valgrind/7324 Giridhar On 07/11/10 09:32 +1100, Nicholas Nethercote said ... > On Fri, 9 Nov 2007, Y Giridhar Appaji Nag wrote: > >> What are my options if I wanted to use valgrind in a static linking >> environment (say, something like busybox). I searched for documents and > > There have been three distinct start-up approaches. With an earlier=20 > version I did do what you are trying to do. But that might have been whe= n=20 > Valgrind used LD_PRELOAD to gain control, which was the first start-up=20 > mechanism. > > For current Valgrinds (3.0 and later) the Valgrind core and tool are=20 > statically linked, and they load the client program. I'm not sure how yo= u=20 > could do what you want. You seem to understand what's involved reasonabl= y=20 > well, you probably have as much idea as anyone else about how best to do= =20 > this... --=20 Y Giridhar Appaji Nag | http://www.appaji.net/ |
|
From: Nicholas N. <nj...@cs...> - 2007-11-09 22:33:28
|
On Fri, 9 Nov 2007, Y Giridhar Appaji Nag wrote: > What are my options if I wanted to use valgrind in a static linking > environment (say, something like busybox). I searched for documents and > list archives and this is a summary of what I discovered: > > [1] http://article.gmane.org/gmane.comp.debugging.valgrind/3 > > Based on the above, it is probably possible to link coregrind and > memcheck object files statically and generate a binary that runs under > valgrind's control. I tried this (used vg 3.2.3) and failed. I > > - Added VEX/libvex_x86_linux.a to the list of libs to be linked in > - removed one of coregrind/libcoregrind_x86_linux_a-m_debuglog.o > coregrind/valgrind-m_debuglog.o because they were the same file. > - moved coregrind/valgrind-launcher.o out of the way because it did > not do much for my purpose. > > After that I did not understand how I should be avoiding the > re-definition of main (my own and coregrind/m_main.c) and _start (crt1.o > and coregrind/m_main.c). Is it possible that I call my own main > sometime in coregrind/m_main.c:main()? What do I do with _start? I > used collect2 directly (instead of ld) and avoided linking in crt1.o but > I could not make much headway after that. > > I came across this: > > [2] http://article.gmane.org/gmane.comp.debugging.valgrind/1230 > > Which indicates that things have changed from 2.1.0 to 2.1.1 and the > earlier thread that I found was from pre-2.1.0 era. > > [3] http://article.gmane.org/gmane.comp.debugging.valgrind/4906 > > What does "visible symbol table entry for the function to be > intercepted" mean? From this thread also, it looks like linking > valgrind code statically to other code is not easy. > > Is it possible to use valgrind the way I am trying to? There have been three distinct start-up approaches. With an earlier version I did do what you are trying to do. But that might have been when Valgrind used LD_PRELOAD to gain control, which was the first start-up mechanism. For current Valgrinds (3.0 and later) the Valgrind core and tool are statically linked, and they load the client program. I'm not sure how you could do what you want. You seem to understand what's involved reasonably well, you probably have as much idea as anyone else about how best to do this... Nick |
|
From: Y G. A. N. <gir...@ap...> - 2007-11-09 10:28:58
|
Hi Valgrinders, What are my options if I wanted to use valgrind in a static linking environment (say, something like busybox). I searched for documents and list archives and this is a summary of what I discovered: [1] http://article.gmane.org/gmane.comp.debugging.valgrind/3 Based on the above, it is probably possible to link coregrind and memcheck object files statically and generate a binary that runs under valgrind's control. I tried this (used vg 3.2.3) and failed. I - Added VEX/libvex_x86_linux.a to the list of libs to be linked in - removed one of coregrind/libcoregrind_x86_linux_a-m_debuglog.o coregrind/valgrind-m_debuglog.o because they were the same file. - moved coregrind/valgrind-launcher.o out of the way because it did not do much for my purpose. After that I did not understand how I should be avoiding the re-definition of main (my own and coregrind/m_main.c) and _start (crt1.o and coregrind/m_main.c). Is it possible that I call my own main sometime in coregrind/m_main.c:main()? What do I do with _start? I used collect2 directly (instead of ld) and avoided linking in crt1.o but I could not make much headway after that. I came across this: [2] http://article.gmane.org/gmane.comp.debugging.valgrind/1230 Which indicates that things have changed from 2.1.0 to 2.1.1 and the earlier thread that I found was from pre-2.1.0 era. [3] http://article.gmane.org/gmane.comp.debugging.valgrind/4906 What does "visible symbol table entry for the function to be intercepted" mean? From this thread also, it looks like linking valgrind code statically to other code is not easy. Is it possible to use valgrind the way I am trying to? Cheers, Giridhar --=20 Y Giridhar Appaji Nag | http://www.appaji.net/ |
|
From: Dan K. <da...@ke...> - 2007-11-08 18:28:05
|
On Nov 7, 2007 5:14 PM, Julian Seward <js...@ac...> wrote: > It's a bug in vg_SP_update_pass in coregrind/m_translate.c. That > function analyses changes to the stack pointer in support of tools > like memcheck that want to know about such changes. Anyway, most > likely it has never before encountered anything as bizarre as > pushing/popping stuff on the stack whilst only changing the lower > half of %esp (like .. why?), and it has produced a bogus piece of > instrumentation code as a result. > > Could you file a bug report so this gets tracked? Filed as http://bugs.kde.org/show_bug.cgi?id=152022 (you might need to change the category). Thanks for the excellent triage! - Dan |
|
From: Julian S. <js...@ac...> - 2007-11-08 01:15:04
|
It's a bug in vg_SP_update_pass in coregrind/m_translate.c. That
function analyses changes to the stack pointer in support of tools
like memcheck that want to know about such changes. Anyway, most
likely it has never before encountered anything as bizarre as
pushing/popping stuff on the stack whilst only changing the lower
half of %esp (like .. why?), and it has produced a bogus piece of
instrumentation code as a result.
Could you file a bug report so this gets tracked? I suspect you
can repro this using a trivial test case which does
"subw $0x28, %sp". Perhaps
int main ( void ) {
__asm__ __volatile__( "subw $0x28, %sp\n"
"movl $0, 0(%esp)\n"
"addw $0x28, %sp" : : : "memory" );
}
J
|
|
From: Dan K. <da...@ke...> - 2007-11-08 00:45:42
|
On Nov 7, 2007 4:41 PM, Julian Seward <js...@ac...> wrote: > > > $ valgrind --took=none --trace-children=yes wine Picasa2.exe > > valgrind: Bad option '--took=none'; aborting. > > That was a typo. I meant --tool=none. Oh, sorry. Yes, it rurns quite well with nulgrind. - Dan |
|
From: Julian S. <js...@ac...> - 2007-11-08 00:42:19
|
> $ valgrind --took=none --trace-children=yes wine Picasa2.exe > valgrind: Bad option '--took=none'; aborting. That was a typo. I meant --tool=none. J |
|
From: Dan K. <da...@ke...> - 2007-11-08 00:34:17
|
On Nov 7, 2007 4:17 PM, Julian Seward <js...@ac...> wrote:
> > 0x758591: subw $0x28, %sp
>
> Looks like you're in some hazy world between 16-bit and 32-bit code.
No doubt. You'd be surprised how many win32 apps use a bit of win16.
> Can you rerun all that stuff but with --trace-flags=10001000 so I
> can see what's going into the instruction selector.
See below. Do you prefer attachments?
> It would also be helpful to know if the app runs ok if you run
> with --took=none.
$ valgrind --took=none --trace-children=yes wine Picasa2.exe
valgrind: Bad option '--took=none'; aborting.
- Dan
==== BB 47751 (0x758580) BBs exec'd 68596482 ====
------------------------ Front end ------------------------
0x758580: pushl %ebp
------ IMark(0x758580, 1) ------
t0 = GET:I32(20)
t1 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t1
STle(t1) = t0
0x758581: movl %esp,%ebp
------ IMark(0x758581, 2) ------
PUT(60) = 0x758581:I32
PUT(20) = GET:I32(16)
0x758583: pushl %ecx
------ IMark(0x758583, 1) ------
PUT(60) = 0x758583:I32
t2 = GET:I32(4)
t3 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t3
STle(t3) = t2
0x758584: pushl %ebx
------ IMark(0x758584, 1) ------
PUT(60) = 0x758584:I32
t4 = GET:I32(12)
t5 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t5
STle(t5) = t4
0x758585: movl $0x0, -4(%ebp)
------ IMark(0x758585, 7) ------
PUT(60) = 0x758585:I32
t6 = Add32(GET:I32(20),0xFFFFFFFC:I32)
STle(t6) = 0x0:I32
0x75858C: pushw %bp
------ IMark(0x75858C, 2) ------
PUT(60) = 0x75858C:I32
t7 = GET:I16(20)
t8 = Sub32(GET:I32(16),0x2:I32)
PUT(16) = t8
STle(t8) = t7
0x75858E: movw %sp,%bp
------ IMark(0x75858E, 3) ------
PUT(60) = 0x75858E:I32
PUT(20) = GET:I16(16)
0x758591: subw $0x28, %sp
------ IMark(0x758591, 4) ------
PUT(60) = 0x758591:I32
t11 = GET:I16(16)
t10 = 0x28:I16
t9 = Sub16(t11,t10)
PUT(32) = 0x5:I32
PUT(36) = 16Uto32(t11)
PUT(40) = 16Uto32(t10)
PUT(44) = 0x0:I32
PUT(16) = t9
0x758595: pushl %eax
------ IMark(0x758595, 1) ------
PUT(60) = 0x758595:I32
t12 = GET:I32(0)
t13 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t13
STle(t13) = t12
0x758596: pushl %ebx
------ IMark(0x758596, 1) ------
PUT(60) = 0x758596:I32
t14 = GET:I32(12)
t15 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t15
STle(t15) = t14
0x758597: pushfl
------ IMark(0x758597, 1) ------
PUT(60) = 0x758597:I32
t16 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t16
t17 =
Or32(x86g_calculate_eflags_all[mcx=0x9]{0x380aab50}(GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32,0x202:I32)
t18 = Or32(t17,And32(GET:I32(48),0x400:I32))
t19 = Or32(t18,And32(Shl32(GET:I32(52),0x15:I8),0x200000:I32))
t20 = Or32(t19,And32(Shl32(GET:I32(56),0x12:I8),0x40000:I32))
STle(t16) = t20
0x758598: popl %eax
------ IMark(0x758598, 1) ------
PUT(60) = 0x758598:I32
t22 = GET:I32(16)
t21 = LDle:I32(t22)
PUT(16) = Add32(t22,0x4:I32)
PUT(0) = t21
0x758599: movl %eax,%ebx
------ IMark(0x758599, 2) ------
PUT(60) = 0x758599:I32
PUT(12) = GET:I32(0)
0x75859B: xorl $0x200000, %eax
------ IMark(0x75859B, 5) ------
PUT(60) = 0x75859B:I32
t23 = GET:I32(0)
t24 = 0x200000:I32
t25 = Xor32(t23,t24)
PUT(32) = 0xF:I32
PUT(36) = t25
PUT(40) = 0x0:I32
PUT(44) = 0x0:I32
PUT(0) = t25
0x7585A0: pushl %eax
------ IMark(0x7585A0, 1) ------
PUT(60) = 0x7585A0:I32
t26 = GET:I32(0)
t27 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t27
STle(t27) = t26
0x7585A1: popfl
------ IMark(0x7585A1, 1) ------
PUT(60) = 0x7585A1:I32
t29 = GET:I32(16)
t28 = LDle:I32(t29)
PUT(16) = Add32(t29,0x4:I32)
PUT(32) = 0x0:I32
PUT(40) = 0x0:I32
PUT(36) = And32(t28,0x8D5:I32)
PUT(44) = 0x0:I32
PUT(48) =
Mux0X(32to8(And32(Shr32(t28,0xA:I8),0x1:I32)),0x1:I32,0xFFFFFFFF:I32)
PUT(52) =
Mux0X(32to8(And32(Shr32(t28,0x15:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(56) =
Mux0X(32to8(And32(Shr32(t28,0x12:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(300) = 0x6:I32
if (CmpNE32(And32(t28,0x40000:I32),0x0:I32)) goto
{EmWarn} 0x7585A2:I32
0x7585A2: pushfl
------ IMark(0x7585A2, 1) ------
PUT(60) = 0x7585A2:I32
t30 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t30
t31 =
Or32(x86g_calculate_eflags_all[mcx=0x9]{0x380aab50}(GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32,0x202:I32)
t32 = Or32(t31,And32(GET:I32(48),0x400:I32))
t33 = Or32(t32,And32(Shl32(GET:I32(52),0x15:I8),0x200000:I32))
t34 = Or32(t33,And32(Shl32(GET:I32(56),0x12:I8),0x40000:I32))
STle(t30) = t34
0x7585A3: popl %eax
------ IMark(0x7585A3, 1) ------
PUT(60) = 0x7585A3:I32
t36 = GET:I32(16)
t35 = LDle:I32(t36)
PUT(16) = Add32(t36,0x4:I32)
PUT(0) = t35
0x7585A4: pushl %ebx
------ IMark(0x7585A4, 1) ------
PUT(60) = 0x7585A4:I32
t37 = GET:I32(12)
t38 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t38
STle(t38) = t37
0x7585A5: popfl
------ IMark(0x7585A5, 1) ------
PUT(60) = 0x7585A5:I32
t40 = GET:I32(16)
t39 = LDle:I32(t40)
PUT(16) = Add32(t40,0x4:I32)
PUT(32) = 0x0:I32
PUT(40) = 0x0:I32
PUT(36) = And32(t39,0x8D5:I32)
PUT(44) = 0x0:I32
PUT(48) =
Mux0X(32to8(And32(Shr32(t39,0xA:I8),0x1:I32)),0x1:I32,0xFFFFFFFF:I32)
PUT(52) =
Mux0X(32to8(And32(Shr32(t39,0x15:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(56) =
Mux0X(32to8(And32(Shr32(t39,0x12:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(300) = 0x6:I32
if (CmpNE32(And32(t39,0x40000:I32),0x0:I32)) goto
{EmWarn} 0x7585A6:I32
0x7585A6: xorl %ebx,%eax
------ IMark(0x7585A6, 2) ------
PUT(60) = 0x7585A6:I32
t43 = GET:I32(0)
t42 = GET:I32(12)
t41 = Xor32(t43,t42)
PUT(32) = 0xF:I32
PUT(36) = t41
PUT(40) = 0x0:I32
PUT(44) = 0x0:I32
PUT(0) = t41
0x7585A8: popl %ebx
------ IMark(0x7585A8, 1) ------
PUT(60) = 0x7585A8:I32
t45 = GET:I32(16)
t44 = LDle:I32(t45)
PUT(16) = Add32(t45,0x4:I32)
PUT(12) = t44
0x7585A9: popl %eax
------ IMark(0x7585A9, 1) ------
PUT(60) = 0x7585A9:I32
t47 = GET:I32(16)
t46 = LDle:I32(t47)
PUT(16) = Add32(t47,0x4:I32)
PUT(0) = t46
0x7585AA: jz-8 0x7585B2
------ IMark(0x7585AA, 2) ------
PUT(60) = 0x7585AA:I32
if
(32to1(x86g_calculate_condition[mcx=0x13]{0x380aa9f0}(0x4:I32,GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32))
goto {Boring} 0x7585B2:I32
goto {Boring} 0x7585AC:I32
. 0 758580 44
. 55 8B EC 51 53 C7 45 FC 00 00 00 00 66 55 66 8B EC 66 83 EC 28 50 53
9C 58 8B D8 35 00 00 20 00 50 9D 9C 58 53 9D 33 C3 5B 58 74 06
------------------------ After tree-building ------------------------
IRBB {
t0:I32 t1:I32 t2:I32 t3:I32 t4:I32 t5:I32 t6:I32 t7:I16
t8:I32 t9:I16 t10:I16 t11:I16 t12:I32 t13:I32 t14:I32 t15:I32
t16:I32 t17:I32 t18:I32 t19:I32 t20:I32 t21:I32 t22:I32 t23:I32
t24:I32 t25:I32 t26:I32 t27:I32 t28:I32 t29:I32 t30:I32 t31:I32
t32:I32 t33:I32 t34:I32 t35:I32 t36:I32 t37:I32 t38:I32 t39:I32
t40:I32 t41:I32 t42:I32 t43:I32 t44:I32 t45:I32 t46:I32 t47:I32
t48:I32 t49:I32 t50:I32 t51:I32 t52:I32 t53:I32 t54:I32 t55:I32
t56:I32 t57:I32 t58:I32 t59:I16 t60:I32 t61:I32 t62:I32 t63:I32
t64:I32 t65:I32 t66:I32 t67:I32 t68:I32 t69:I32 t70:I32 t71:I32
t72:I32 t73:I32 t74:I32 t75:I32 t76:I32 t77:I32 t78:I32 t79:I32
t80:I32 t81:I32 t82:I32 t83:I32 t84:I32 t85:I32 t86:I32 t87:I32
t88:I32 t89:I32 t90:I32 t91:I32 t92:I8 t93:I32 t94:I32 t95:I32
t96:I8 t97:I32 t98:I32 t99:I32 t100:I8 t101:I32
t102:I32 t103:I1
t104:I32 t105:I32 t106:I32 t107:I32 t108:I32 t109:I32
t110:I32 t111:I32
t112:I32 t113:I32 t114:I32 t115:I32 t116:I32 t117:I32
t118:I32 t119:I32
t120:I32 t121:I32 t122:I32 t123:I32 t124:I32 t125:I32
t126:I32 t127:I32
t128:I32 t129:I32 t130:I8 t131:I32 t132:I32 t133:I32
t134:I8 t135:I32
t136:I32 t137:I32 t138:I8 t139:I32 t140:I32 t141:I1
t142:I32 t143:I32
t144:I32 t145:I1 t146:I32 t147:I32 t148:I32 t149:I32
t150:I32 t151:I32
t152:I32 t153:I8 t154:I32 t155:I8 t156:I32 t157:I8
t158:I32 t159:I8
t160:I32 t161:I8 t162:I32 t163:I8 t164:I32 t165:I32
t166:I1 t167:I1
t168:I32 t169:I32 t170:I32 t171:I32 t172:I32 t173:I32
t174:I1 t175:I32
t176:I32 t177:I32 t178:I32 t179:I32 t180:I32 t181:I1
t182:I32 t183:I32
t184:I32 t185:I32 t186:I32 t187:I32 t188:I1 t189:I32
t190:I32 t191:I32
t192:I32 t193:I32 t194:I1 t195:I32 t196:I16 t197:I32
t198:I32 t199:I32
t200:I32 t201:I1 t202:I32 t203:I32 t204:I16 t205:I16
t206:I16 t207:I16
t208:I16 t209:I32 t210:I32 t211:I32 t212:I32 t213:I32
t214:I32 t215:I32
t216:I32 t217:I32 t218:I1 t219:I32 t220:I32 t221:I32
t222:I32 t223:I32
t224:I1 t225:I32 t226:I32 t227:I32 t228:I32 t229:I32
t230:I1 t231:I32
t232:I32 t233:I1 t234:I32 t235:I32 t236:I1 t237:I32
t238:I32 t239:I32
t240:I32 t241:I32 t242:I32 t243:I32 t244:I32 t245:I32
t246:I32 t247:I32
t248:I32 t249:I32 t250:I32 t251:I32 t252:I32 t253:I32
t254:I32 t255:I32
t256:I32 t257:I32 t258:I32 t259:I32 t260:I32 t261:I32
t262:I32 t263:I32
t264:I32 t265:I32 t266:I32 t267:I1 t268:I32 t269:I32
t270:I32 t271:I32
t272:I32 t273:I32 t274:I32 t275:I32 t276:I32 t277:I32
t278:I32 t279:I32
t280:I32 t281:I32 t282:I32 t283:I32 t284:I32 t285:I32
t286:I32 t287:I32
t288:I32 t289:I32 t290:I1 t291:I32 t292:I32 t293:I32
t294:I32 t295:I32
t296:I32 t297:I32 t298:I32 t299:I32 t300:I32 t301:I32
t302:I32 t303:I32
t304:I32 t305:I32 t306:I32 t307:I32 t308:I32 t309:I32
t310:I32 t311:I32
t312:I1 t313:I32 t314:I1 t315:I32 t316:I32 t317:I32
t318:I32 t319:I32
t320:I32 t321:I32 t322:I32 t323:I32 t324:I32 t325:I32
t326:I32 t327:I32
t328:I1 t329:I32 t330:I1 t331:I32 t332:I32 t333:I32
t334:I32 t335:I32
t336:I32 t337:I32 t338:I32 t339:I32 t340:I32 t341:I32
t342:I32 t343:I32
t344:I32 t345:I1 t346:I32 t347:I32 t348:I32 t349:I32
t350:I32 t351:I32
t352:I32 t353:I32 t354:I32 t355:I32 t356:I32 t357:I32
t358:I8 t359:I8
t360:I8 t361:I1 t362:I32 t363:I32 t364:I32 t365:I32
t366:I32 t367:I1
t368:I32 t369:I32 t370:I32 t371:I32 t372:I32 t373:I32
t374:I32 t375:I32
t376:I32 t377:I32 t378:I32 t379:I32 t380:I8 t381:I8
t382:I8 t383:I1
t384:I32 t385:I32 t386:I32 t387:I32 t388:I32 t389:I1
t390:I32 t391:I32
t392:I32 t393:I32 t394:I32 t395:I32 t396:I32 t397:I32
t398:I32 t399:I32
t400:I32 t401:I32 t402:I8 t403:I8 t404:I8 t405:I1
t406:I32 t407:I32
t408:I32 t409:I32 t410:I32 t411:I32 t412:I32 t413:I32
t414:I32 t415:I32
t416:I32 t417:I32 t418:I32 t419:I1 t420:I1 t421:I1
t422:I32 t423:I32
t424:I32 t425:I32 t426:I32 t427:I32 t428:I32 t429:I32
t430:I32 t431:I32
t432:I32 t433:I32 t434:I32 t435:I32 t436:I32 t437:I32
t438:I32 t439:I32
t440:I32 t441:I32 t442:I32 t443:I32 t444:I32 t445:I32
t446:I32 t447:I32
t448:I32 t449:I32 t450:I32 t451:I32 t452:I32 t453:I32
t454:I32 t455:I32
t456:I32 t457:I32 t458:I1 t459:I32 t460:I32 t461:I32
t462:I32 t463:I32
t464:I32 t465:I32 t466:I32 t467:I32 t468:I32 t469:I32
t470:I32 t471:I32
t472:I32 t473:I32 t474:I32 t475:I32 t476:I32 t477:I32
t478:I32 t479:I32
t480:I1 t481:I32 t482:I32 t483:I32 t484:I32 t485:I32
t486:I32 t487:I32
t488:I32 t489:I32 t490:I32 t491:I32 t492:I32 t493:I32
t494:I32 t495:I32
t496:I32 t497:I32 t498:I32 t499:I32 t500:I32 t501:I32
t502:I1 t503:I32
t504:I1 t505:I32 t506:I32 t507:I32 t508:I32 t509:I32
t510:I32 t511:I32
t512:I32 t513:I32 t514:I32 t515:I32 t516:I1 t517:I32
t518:I1 t519:I32
t520:I32 t521:I32 t522:I32 t523:I32 t524:I32 t525:I32
t526:I32 t527:I32
t528:I32 t529:I32 t530:I32 t531:I32 t532:I32 t533:I1
t534:I32 t535:I32
t536:I32 t537:I32 t538:I32 t539:I32 t540:I32 t541:I32
t542:I32 t543:I32
t544:I32 t545:I32 t546:I8 t547:I8 t548:I8 t549:I1
t550:I32 t551:I32
t552:I32 t553:I32 t554:I32 t555:I1 t556:I32 t557:I32
t558:I32 t559:I32
t560:I32 t561:I32 t562:I32 t563:I32 t564:I32 t565:I32
t566:I32 t567:I32
t568:I8 t569:I8 t570:I8 t571:I1 t572:I32 t573:I32
t574:I32 t575:I32
t576:I32 t577:I1 t578:I32 t579:I32 t580:I32 t581:I32
t582:I32 t583:I32
t584:I32 t585:I32 t586:I32 t587:I32 t588:I32 t589:I32
t590:I8 t591:I8
t592:I8 t593:I1 t594:I32 t595:I32 t596:I32 t597:I32
t598:I32 t599:I32
t600:I32 t601:I32 t602:I32 t603:I32 t604:I32 t605:I32
t606:I32 t607:I1
t608:I1 t609:I1 t610:I32 t611:I32 t612:I1 t613:I32
t614:I32 t615:I32
t616:I32 t617:I32 t618:I32 t619:I32 t620:I1 t621:I32
t622:I32 t623:I32
t624:I32 t625:I32 t626:I32 t627:I32 t628:I32 t629:I1
t630:I1 t631:I32
t632:I32 t633:I32 t634:I1 t635:I1 t636:I1 t637:I1
t638:I1 t639:I32
t640:I32
------ IMark(0x758580, 1) ------
t169 = GET:I32(336)
t172 = Or32(t169,Neg32(t169))
t48 = Sub32(GET:I32(16),0x4:I32)
t168 = GET:I32(340)
t0 = GET:I32(20)
PUT(336) = t172
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t48)
PUT(16) = t48
DIRTY CmpNEZ32(t172) RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_value_check4_fail){0x38005760}()
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t48,t168)
STle(t48) = t0
------ IMark(0x758581, 2) ------
PUT(340) = 0x0:I32
PUT(20) = t48
------ IMark(0x758583, 1) ------
PUT(60) = 0x758583:I32
t51 = Sub32(t48,0x4:I32)
t176 = GET:I32(324)
t2 = GET:I32(4)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t51)
PUT(16) = t51
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t51,t176)
STle(t51) = t2
------ IMark(0x758584, 1) ------
PUT(60) = 0x758584:I32
t183 = GET:I32(332)
t4 = GET:I32(12)
t53 = Sub32(t51,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t53)
PUT(16) = t53
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t53,t183)
STle(t53) = t4
------ IMark(0x758585, 7) ------
PUT(60) = 0x758585:I32
t55 = Add32(t48,0xFFFFFFFC:I32)
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t55,0x0:I32)
STle(t55) = 0x0:I32
------ IMark(0x75858C, 2) ------
PUT(60) = 0x75858C:I32
t57 = Sub32(t53,0x2:I32)
t196 = GET:I16(340)
t7 = GET:I16(20)
PUT(336) = 0x0:I32
DIRTY 1:I1 ::: VG_(unknown_SP_update)[rp=2]{0x38025f32}(GET:I32(16),t57)
PUT(16) = t57
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV16le)[rp=2]{0x38005920}(t57,16Uto32(t196))
STle(t57) = t7
------ IMark(0x75858E, 3) ------
t204 = GET:I16(336)
t59 = GET:I16(16)
PUT(340) = t204
PUT(20) = t59
------ IMark(0x758591, 4) ------
t9 = Sub16(t59,0x28:I16)
PUT(336) = Or16(t204,Neg16(t204))
DIRTY 1:I1 ::: VG_(unknown_SP_update)[rp=2]{0x38025f32}(GET:I32(16),t9)
PUT(16) = t9
------ IMark(0x758595, 1) ------
PUT(60) = 0x758595:I32
t213 = GET:I32(336)
t216 = Or32(t213,Neg32(t213))
t62 = Sub32(GET:I32(16),0x4:I32)
t212 = GET:I32(320)
t12 = GET:I32(0)
PUT(336) = t216
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t62)
PUT(16) = t62
DIRTY CmpNEZ32(t216) RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_value_check4_fail){0x38005760}()
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t62,t212)
STle(t62) = t12
------ IMark(0x758596, 1) ------
PUT(60) = 0x758596:I32
t64 = Sub32(t62,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t64)
PUT(16) = t64
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t64,t183)
STle(t64) = t4
------ IMark(0x758597, 1) ------
PUT(60) = 0x758597:I32
t66 = Sub32(t64,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t66)
PUT(16) = t66
t237 = 1Sto32(CmpNEZ32(1Sto32(CmpNEZ32(16Uto32(t204)))))
t152 = x86g_calculate_eflags_all[mcx=0x9]{0x380aab50}(0x5:I32,16Uto32(t59),0x28:I32,0x0:I32):I32
t246 = And32(t237,And32(Or32(Not32(t152),t237),0xFFFFFDFD:I32))
t68 = Or32(t152,0x202:I32)
t75 = And32(GET:I32(48),0x400:I32)
t263 = And32(t246,And32(Or32(Not32(t68),t246),Not32(t75)))
t74 = Or32(t68,t75)
t78 = And32(Shl32(GET:I32(52),0x15:I8),0x200000:I32)
t286 = And32(t263,And32(Or32(Not32(t74),t263),Not32(t78)))
t77 = Or32(t74,t78)
t82 = And32(Shl32(GET:I32(56),0x12:I8),0x40000:I32)
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t66,And32(t286,And32(Or32(Not32(t77),t286),Not32(t82))))
STle(t66) = Or32(t77,t82)
------ IMark(0x758598, 1) ------
PUT(60) = 0x758598:I32
t316 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t66)
t21 = LDle:I32(t66)
------ IMark(0x758599, 2) ------
PUT(332) = t316
PUT(12) = t21
------ IMark(0x75859B, 5) ------
t25 = Xor32(t21,0x200000:I32)
PUT(320) = t316
PUT(0) = t25
------ IMark(0x7585A0, 1) ------
PUT(60) = 0x7585A0:I32
t87 = Sub32(Add32(t66,0x4:I32),0x4:I32)
PUT(336) = 0x0:I32
PUT(16) = t87
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t87,t316)
STle(t87) = t25
------ IMark(0x7585A1, 1) ------
PUT(60) = 0x7585A1:I32
t332 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t87)
t28 = LDle:I32(t87)
t89 = Add32(t87,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_die_mem_stack_4[rp=1]{0x3800a1c0}(t89)
PUT(16) = t89
PUT(32) = 0x0:I32
PUT(360) = 0x0:I32
PUT(40) = 0x0:I32
t342 = And32(t332,And32(Or32(t28,t332),0x8D5:I32))
t90 = And32(t28,0x8D5:I32)
PUT(356) = t342
PUT(36) = t90
PUT(44) = 0x0:I32
t347 = Shr32(t332,0xA:I8)
t94 = Shr32(t28,0xA:I8)
t153 = 32to8(And32(t94,0x1:I32))
t364 = Or32(Mux0X(t153,0x0:I32,0x0:I32),1Sto32(CmpNEZ8(32to8(And32(t347,And32(Or32(t94,t347),0x1:I32))))))
t154 = Mux0X(t153,0x1:I32,0xFFFFFFFF:I32)
PUT(48) = t154
t369 = Shr32(t332,0x15:I8)
t98 = Shr32(t28,0x15:I8)
t155 = 32to8(And32(t98,0x1:I32))
t156 = Mux0X(t155,0x0:I32,0x1:I32)
PUT(52) = t156
t391 = Shr32(t332,0x12:I8)
t102 = Shr32(t28,0x12:I8)
t157 = 32to8(And32(t102,0x1:I32))
t158 = Mux0X(t157,0x0:I32,0x1:I32)
PUT(56) = t158
PUT(300) = 0x6:I32
DIRTY CmpNEZ32(And32(t332,And32(Or32(t28,t332),0x40000:I32)))
RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_value_check0_fail){0x380057a0}()
if (CmpNE32(And32(t28,0x40000:I32),0x0:I32)) goto {EmWarn} 0x7585A2:I32
------ IMark(0x7585A2, 1) ------
PUT(60) = 0x7585A2:I32
t105 = Sub32(t89,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_new_mem_stack_4[rp=1]{0x3800aa50}(t105)
PUT(16) = t105
t430 = And32(t342,And32(Or32(t90,t342),0x8D5:I32))
t112 = And32(t90,0x8D5:I32)
t439 = And32(t430,And32(Or32(Not32(t112),t430),0xFFFFFDFD:I32))
t107 = Or32(t112,0x202:I32)
t446 = And32(t364,And32(Or32(t154,t364),0x400:I32))
t114 = And32(t154,0x400:I32)
t455 = And32(Or32(t439,t446),And32(Or32(Not32(t107),t439),Or32(Not32(t114),t446)))
t113 = Or32(t107,t114)
t460 = Shl32(Or32(Mux0X(t155,0x0:I32,0x0:I32),1Sto32(CmpNEZ8(32to8(And32(t369,And32(Or32(t98,t369),0x1:I32)))))),0x15:I8)
t118 = Shl32(t156,0x15:I8)
t468 = And32(t460,And32(Or32(t118,t460),0x200000:I32))
t117 = And32(t118,0x200000:I32)
t477 = And32(Or32(t455,t468),And32(Or32(Not32(t113),t455),Or32(Not32(t117),t468)))
t116 = Or32(t113,t117)
t482 = Shl32(Or32(Mux0X(t157,0x0:I32,0x0:I32),1Sto32(CmpNEZ8(32to8(And32(t391,And32(Or32(t102,t391),0x1:I32)))))),0x12:I8)
t122 = Shl32(t158,0x12:I8)
t490 = And32(t482,And32(Or32(t122,t482),0x40000:I32))
t121 = And32(t122,0x40000:I32)
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t105,And32(Or32(t477,t490),And32(Or32(Not32(t116),t477),Or32(Not32(t121),t490))))
STle(t105) = Or32(t116,t121)
------ IMark(0x7585A3, 1) ------
PUT(60) = 0x7585A3:I32
t506 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t105)
t35 = LDle:I32(t105)
PUT(320) = t506
PUT(0) = t35
------ IMark(0x7585A4, 1) ------
PUT(60) = 0x7585A4:I32
t125 = Sub32(Add32(t105,0x4:I32),0x4:I32)
PUT(336) = 0x0:I32
PUT(16) = t125
DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_STOREV32le)[rp=2]{0x380059f0}(t125,t316)
STle(t125) = t21
------ IMark(0x7585A5, 1) ------
PUT(60) = 0x7585A5:I32
t520 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t125)
t39 = LDle:I32(t125)
t127 = Add32(t125,0x4:I32)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_die_mem_stack_4[rp=1]{0x3800a1c0}(t127)
PUT(16) = t127
PUT(32) = 0x0:I32
PUT(360) = 0x0:I32
PUT(40) = 0x0:I32
PUT(356) = And32(t520,And32(Or32(t39,t520),0x8D5:I32))
PUT(36) = And32(t39,0x8D5:I32)
PUT(44) = 0x0:I32
PUT(48) = Mux0X(32to8(And32(Shr32(t39,0xA:I8),0x1:I32)),0x1:I32,0xFFFFFFFF:I32)
PUT(52) = Mux0X(32to8(And32(Shr32(t39,0x15:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(56) = Mux0X(32to8(And32(Shr32(t39,0x12:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(300) = 0x6:I32
DIRTY CmpNEZ32(And32(t520,And32(Or32(t39,t520),0x40000:I32)))
RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_value_check0_fail){0x380057a0}()
if (CmpNE32(And32(t39,0x40000:I32),0x0:I32)) goto {EmWarn} 0x7585A6:I32
------ IMark(0x7585A6, 2) ------
t610 = Or32(t506,t316)
t41 = Xor32(t35,t21)
PUT(32) = 0xF:I32
PUT(356) = t610
PUT(36) = t41
PUT(360) = 0x0:I32
PUT(40) = 0x0:I32
PUT(44) = 0x0:I32
------ IMark(0x7585A8, 1) ------
PUT(60) = 0x7585A8:I32
t614 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t127)
t143 = Add32(t127,0x4:I32)
t44 = LDle:I32(t127)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_die_mem_stack_4[rp=1]{0x3800a1c0}(t143)
PUT(16) = t143
PUT(332) = t614
PUT(12) = t44
------ IMark(0x7585A9, 1) ------
PUT(60) = 0x7585A9:I32
t622 = DIRTY 1:I1 RdFX-gst(16,4) RdFX-gst(60,4) :::
MC_(helperc_LOADV32le)[rp=1]{0x38005dd0}(t143)
t144 = Add32(t143,0x4:I32)
t46 = LDle:I32(t143)
PUT(336) = 0x0:I32
DIRTY 1:I1 RdFX-gst(16,4) ::: track_die_mem_stack_4[rp=1]{0x3800a1c0}(t144)
PUT(16) = t144
PUT(320) = t622
PUT(0) = t46
------ IMark(0x7585AA, 2) ------
PUT(60) = 0x7585AA:I32
DIRTY 32to1(1Uto32(CmpNEZ32(t610))) RdFX-gst(16,4) RdFX-gst(60,4)
::: MC_(helperc_value_check0_fail){0x380057a0}()
if (32to1(1Uto32(CmpEQ32(t41,0x0:I32)))) goto {Boring} 0x7585B2:I32
goto {Boring} 0x7585AC:I32
}
vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion
`typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
vex storage: T total 1290600092 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==7065== at 0x380165D9: report_and_quit (m_libcassert.c:136)
==7065== by 0x3: ???
==7065== by 0x3: ???
==7065== by 0x621CE9F3: ???
==7065== by 0x621CEA63: ???
==7065== by 0x38017D1F: vgPlain_vprintf (m_libcprint.c:103)
==7065== by 0x38017EB1: vgPlain_message (m_libcprint.c:340)
==7065== by 0x621CE9F3: ???
==7065== by 0x3812FA62: (within
/usr/local/valgrind-3.2.3-wine/lib/valgrind/x86-linux/memcheck)
==7065== by 0x621CEA93: ???
==7065== by 0xA646573: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==7065== at 0x758580: ???
==7065== by 0x4522C2D: start_process (process.c:839)
==7065== by 0x402D9D6: (within /home/dank/wine-git/libs/wine/libwine.so.1.0)
|
|
From: Julian S. <js...@ac...> - 2007-11-08 00:18:25
|
> 0x758591: subw $0x28, %sp Looks like you're in some hazy world between 16-bit and 32-bit code. I suspect the above instruction is interacting badly with one of Memcheck's analysis passes. Can you rerun all that stuff but with --trace-flags=10001000 so I can see what's going into the instruction selector. It would also be helpful to know if the app runs ok if you run with --took=none. J |
|
From: Dan K. <da...@ke...> - 2007-11-07 23:50:29
|
On Nov 7, 2007 1:50 PM, Julian Seward <js...@ac...> wrote:
> Sounds like you've got an IR helper call with an argument type
> which isn't handled by the backend (instruction selector). Find
> the basic block containing the problem insn
Here y'go. Thanks,
Dan
==== BB 47752 (0x758580) BBs exec'd 68579743 ====
------------------------ Front end ------------------------
0x758580: pushl %ebp
------ IMark(0x758580, 1) ------
t0 = GET:I32(20)
t1 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t1
STle(t1) = t0
0x758581: movl %esp,%ebp
------ IMark(0x758581, 2) ------
PUT(60) = 0x758581:I32
PUT(20) = GET:I32(16)
0x758583: pushl %ecx
------ IMark(0x758583, 1) ------
PUT(60) = 0x758583:I32
t2 = GET:I32(4)
t3 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t3
STle(t3) = t2
0x758584: pushl %ebx
------ IMark(0x758584, 1) ------
PUT(60) = 0x758584:I32
t4 = GET:I32(12)
t5 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t5
STle(t5) = t4
0x758585: movl $0x0, -4(%ebp)
------ IMark(0x758585, 7) ------
PUT(60) = 0x758585:I32
t6 = Add32(GET:I32(20),0xFFFFFFFC:I32)
STle(t6) = 0x0:I32
0x75858C: pushw %bp
------ IMark(0x75858C, 2) ------
PUT(60) = 0x75858C:I32
t7 = GET:I16(20)
t8 = Sub32(GET:I32(16),0x2:I32)
PUT(16) = t8
STle(t8) = t7
0x75858E: movw %sp,%bp
------ IMark(0x75858E, 3) ------
PUT(60) = 0x75858E:I32
PUT(20) = GET:I16(16)
0x758591: subw $0x28, %sp
------ IMark(0x758591, 4) ------
PUT(60) = 0x758591:I32
t11 = GET:I16(16)
t10 = 0x28:I16
t9 = Sub16(t11,t10)
PUT(32) = 0x5:I32
PUT(36) = 16Uto32(t11)
PUT(40) = 16Uto32(t10)
PUT(44) = 0x0:I32
PUT(16) = t9
0x758595: pushl %eax
------ IMark(0x758595, 1) ------
PUT(60) = 0x758595:I32
t12 = GET:I32(0)
t13 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t13
STle(t13) = t12
0x758596: pushl %ebx
------ IMark(0x758596, 1) ------
PUT(60) = 0x758596:I32
t14 = GET:I32(12)
t15 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t15
STle(t15) = t14
0x758597: pushfl
------ IMark(0x758597, 1) ------
PUT(60) = 0x758597:I32
t16 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t16
t17 =
Or32(x86g_calculate_eflags_all[mcx=0x9]{0x380aab50}(GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32,0x202:I32)
t18 = Or32(t17,And32(GET:I32(48),0x400:I32))
t19 = Or32(t18,And32(Shl32(GET:I32(52),0x15:I8),0x200000:I32))
t20 = Or32(t19,And32(Shl32(GET:I32(56),0x12:I8),0x40000:I32))
STle(t16) = t20
0x758598: popl %eax
------ IMark(0x758598, 1) ------
PUT(60) = 0x758598:I32
t22 = GET:I32(16)
t21 = LDle:I32(t22)
PUT(16) = Add32(t22,0x4:I32)
PUT(0) = t21
0x758599: movl %eax,%ebx
------ IMark(0x758599, 2) ------
PUT(60) = 0x758599:I32
PUT(12) = GET:I32(0)
0x75859B: xorl $0x200000, %eax
------ IMark(0x75859B, 5) ------
PUT(60) = 0x75859B:I32
t23 = GET:I32(0)
t24 = 0x200000:I32
t25 = Xor32(t23,t24)
PUT(32) = 0xF:I32
PUT(36) = t25
PUT(40) = 0x0:I32
PUT(44) = 0x0:I32
PUT(0) = t25
0x7585A0: pushl %eax
------ IMark(0x7585A0, 1) ------
PUT(60) = 0x7585A0:I32
t26 = GET:I32(0)
t27 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t27
STle(t27) = t26
0x7585A1: popfl
------ IMark(0x7585A1, 1) ------
PUT(60) = 0x7585A1:I32
t29 = GET:I32(16)
t28 = LDle:I32(t29)
PUT(16) = Add32(t29,0x4:I32)
PUT(32) = 0x0:I32
PUT(40) = 0x0:I32
PUT(36) = And32(t28,0x8D5:I32)
PUT(44) = 0x0:I32
PUT(48) =
Mux0X(32to8(And32(Shr32(t28,0xA:I8),0x1:I32)),0x1:I32,0xFFFFFFFF:I32)
PUT(52) =
Mux0X(32to8(And32(Shr32(t28,0x15:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(56) =
Mux0X(32to8(And32(Shr32(t28,0x12:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(300) = 0x6:I32
if (CmpNE32(And32(t28,0x40000:I32),0x0:I32)) goto
{EmWarn} 0x7585A2:I32
0x7585A2: pushfl
------ IMark(0x7585A2, 1) ------
PUT(60) = 0x7585A2:I32
t30 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t30
t31 =
Or32(x86g_calculate_eflags_all[mcx=0x9]{0x380aab50}(GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32,0x202:I32)
t32 = Or32(t31,And32(GET:I32(48),0x400:I32))
t33 = Or32(t32,And32(Shl32(GET:I32(52),0x15:I8),0x200000:I32))
t34 = Or32(t33,And32(Shl32(GET:I32(56),0x12:I8),0x40000:I32))
STle(t30) = t34
0x7585A3: popl %eax
------ IMark(0x7585A3, 1) ------
PUT(60) = 0x7585A3:I32
t36 = GET:I32(16)
t35 = LDle:I32(t36)
PUT(16) = Add32(t36,0x4:I32)
PUT(0) = t35
0x7585A4: pushl %ebx
------ IMark(0x7585A4, 1) ------
PUT(60) = 0x7585A4:I32
t37 = GET:I32(12)
t38 = Sub32(GET:I32(16),0x4:I32)
PUT(16) = t38
STle(t38) = t37
0x7585A5: popfl
------ IMark(0x7585A5, 1) ------
PUT(60) = 0x7585A5:I32
t40 = GET:I32(16)
t39 = LDle:I32(t40)
PUT(16) = Add32(t40,0x4:I32)
PUT(32) = 0x0:I32
PUT(40) = 0x0:I32
PUT(36) = And32(t39,0x8D5:I32)
PUT(44) = 0x0:I32
PUT(48) =
Mux0X(32to8(And32(Shr32(t39,0xA:I8),0x1:I32)),0x1:I32,0xFFFFFFFF:I32)
PUT(52) =
Mux0X(32to8(And32(Shr32(t39,0x15:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(56) =
Mux0X(32to8(And32(Shr32(t39,0x12:I8),0x1:I32)),0x0:I32,0x1:I32)
PUT(300) = 0x6:I32
if (CmpNE32(And32(t39,0x40000:I32),0x0:I32)) goto
{EmWarn} 0x7585A6:I32
0x7585A6: xorl %ebx,%eax
------ IMark(0x7585A6, 2) ------
PUT(60) = 0x7585A6:I32
t43 = GET:I32(0)
t42 = GET:I32(12)
t41 = Xor32(t43,t42)
PUT(32) = 0xF:I32
PUT(36) = t41
PUT(40) = 0x0:I32
PUT(44) = 0x0:I32
PUT(0) = t41
0x7585A8: popl %ebx
------ IMark(0x7585A8, 1) ------
PUT(60) = 0x7585A8:I32
t45 = GET:I32(16)
t44 = LDle:I32(t45)
PUT(16) = Add32(t45,0x4:I32)
PUT(12) = t44
0x7585A9: popl %eax
------ IMark(0x7585A9, 1) ------
PUT(60) = 0x7585A9:I32
t47 = GET:I32(16)
t46 = LDle:I32(t47)
PUT(16) = Add32(t47,0x4:I32)
PUT(0) = t46
0x7585AA: jz-8 0x7585B2
------ IMark(0x7585AA, 2) ------
PUT(60) = 0x7585AA:I32
if
(32to1(x86g_calculate_condition[mcx=0x13]{0x380aa9f0}(0x4:I32,GET:I32(32),GET:I32(36),GET:I32(40),GET:I32(44)):I32))
goto {Boring} 0x7585B2:I32
goto {Boring} 0x7585AC:I32
. 0 758580 44
. 55 8B EC 51 53 C7 45 FC 00 00 00 00 66 55 66 8B EC 66 83 EC 28 50 53
9C 58 8B D8 35 00 00 20 00 50 9D 9C 58 53 9D 33 C3 5B 58 74 06
vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion
`typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
vex storage: T total 1290621308 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==6889== at 0x380165D9: report_and_quit (m_libcassert.c:136)
==6889== by 0x3: ???
==6889== by 0x3: ???
==6889== by 0x621B99F3: ???
==6889== by 0x621B9A63: ???
==6889== by 0x38017D1F: vgPlain_vprintf (m_libcprint.c:103)
==6889== by 0x38017EB1: vgPlain_message (m_libcprint.c:340)
==6889== by 0x621B99F3: ???
==6889== by 0x3812FA62: (within
/usr/local/valgrind-3.2.3-wine/lib/valgrind/x86-linux/memcheck)
==6889== by 0x621B9A93: ???
==6889== by 0xA646573: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==6889== at 0x758580: ???
==6889== by 0x4522C2D: start_process (process.c:839)
==6889== by 0x402D9D6: (within /home/dank/wine-git/libs/wine/libwine.so.1.0)
|
|
From: Julian S. <js...@ac...> - 2007-11-07 21:51:05
|
> vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion > `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed. > vex storage: T total 2095603544 bytes allocated Sounds like you've got an IR helper call with an argument type which isn't handled by the backend (instruction selector). Find the basic block containing the problem insn: Rerun with --vex-guest-chase-thresh=0 --trace-flags=10000000 --trace-notbelow=999999. Once you know the translation number that it craps out at, replace the 999999 with that. Rerun. That should show you the actual basic block it is complaining about. Send. J |
|
From: Nicholas N. <nj...@cs...> - 2007-11-07 21:06:41
|
On Wed, 7 Nov 2007, Mohamed Mansour wrote: > Thanks for the reply. I was actually looking for collecting UserTime > sampling only, so this works great for me. Any numbers reported by Callgrind (which is different to Cachegrind) will be very approximate only. Nick |
|
From: Dan K. <da...@ke...> - 2007-11-07 20:34:01
|
I'm using the procedure documented at http://wiki.winehq.org/Wine_and_Valgrind and automated by http://kegel.com/wine/valgrind/valgrind-build.sh to build a copy of valgrind-3.2.3 with Eric Pouech's Wine support patches (rollup at http://kegel.com/wine/valgrind/vg-3.2.3.patch ). This works fairly well when running the Wine conformance test suite; there might be a few issues, but no aborts. But when I tried valgrinding Picasa running under Wine, it fell over with an error (see below). I've searched around a bit for similar errors, but haven't seen any. Suggestions? Thanks, Dan vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed. vex storage: T total 2095603544 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==2614== at 0x380163BA: report_and_quit (m_libcassert.c:136) ==2614== by 0x43988FF: ??? ==2614== by 0x43989CF: ??? ==2614== by 0x380178C9: send_bytes_to_logging_sink (m_libcprint.c:55) ==2614== by 0x1FF7: ??? ==2614== by 0x43989E7: ??? ==2614== by 0x3: ??? ==2614== by 0x3: ??? ==2614== by 0x43989E7: ??? ==2614== by 0x4398A57: ??? ==2614== by 0x380179BB: vgPlain_vprintf (m_libcprint.c:103) ==2614== by 0x43989E7: ??? ==2614== by 0x3: ??? ==2614== by 0x381308E6: (within /usr/local/valgrind-3.2.3-wine/lib/valgrind/x86-linux/memcheck) ==2614== by 0x4398A87: ??? ==2614== by 0xA646573: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==2614== at 0x758620: ??? |
|
From: Mohamed M. <man...@gm...> - 2007-11-07 14:53:58
|
Thanks for the reply. I was actually looking for collecting UserTime sampling only, so this works great for me. -- Mohamed On Nov 7, 2007 2:50 AM, Josef Weidendorfer <Jos...@gm...> wrote: > On Wednesday 07 November 2007, Mohamed Mansour wrote: > > Hi, > > > > I am using cachegrind to measure bottlenecks for a C++ process. This > process > > is part of a distributed system and in the course of fulfilling a > request it > > will make one or more blocking remote calls. > > > > Does cachegrind include the blocking times in the numbers it reports? > > No. > Use system wide sampling to get an idea what happens in the system. > Blocking time waiting on an external event probably will show up as part > of the kernel idle loop. > > Josef > > PS: You can check out --collect-systime=yes with callgrind to get event > numbers > for wall clock time spent in system calls. You will get 2 new events: > "sysCount" > for the number of system calls executed, and "sysTime" for the number of > milliseconds spent in the system calls. However, you should be very > careful > when interpreting these numbers. > > > > > > > These are the options I start with: > > --simulate-cache=no > > --tool=callgrind > > --instr-atstart=no > > > > > > Thanks, > > Mohamed > > > > > |