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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Dirk M. <mu...@kd...> - 2003-12-31 14:32:54
|
CVS commit by mueller:
mark the braced expression as C(++) extension
M +4 -1 valgrind.h 1.23
--- valgrind/include/valgrind.h #1.22:1.23
@@ -170,8 +170,11 @@ typedef
} Vg_ClientRequest;
+#ifndef __GNUC__
+#define __extension__
+#endif
/* Returns 1 if running on Valgrind, 0 if running on the real CPU.
Currently implemented but untested. */
-#define RUNNING_ON_VALGRIND \
+#define RUNNING_ON_VALGRIND __extension__ \
({unsigned int _qzz_res; \
VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0 /* returned if not */, \
|
|
From: Josef W. <Jos...@gm...> - 2003-12-31 13:04:21
|
Am Mittwoch, 31. Dezember 2003 14:51 schrieb Nick:
> > You are using VG_(get_fnname_if_entry)() only for the first instruction
> > of every basic block. I'm not quite sure this is always correct. Does it
> > work if you check at every instruction?
>
> Given that it's incorrect, then that means that I'm getting less than or
> equal to the amount of calls to the code added during instrumentation that
> I should. But I haven't seen evidence of that yet. Nevertheless, I'll do =
as
> you suggest.
Shouldn't be the number of calls reported the same?
> I got the idea yesterday of enclosing CALLs with debugging statements, so
> I wouldn't have to deal with the 99 different RETs as you said ;)
Sorry, I don't get your point.
>
> VG_(call_helper_0_0)(newCb, (Addr) &printBeforeCall);
> VG_(copy_UInstr)(newCb, u);
> VG_(call_helper_0_0)(newCb, (Addr) &printAfterCall);
>
> However, I still can't figure out what the heck is going on.
> printAfterCall never gets called, for one.
=46or Valgrind UCode, a x86 CALL is translated to a PUSH/JMP. And every jum=
p is=20
translated to a jump to valgrinds main loop. So your second helper call=20
(printAfterCall) of course is dead code. Look at the info which=20
=2D-trace-codegen is giving you.
> shouldn't a function return (by whatever message) result in the instructi=
on
> following the call being executed?
After return, a new basic block is executed, but your call to printAfterCal=
l=20
is put at a dead end of the basic block where the call started.
> void printName(void){
> Addr a;
> ThreadId tid;
>
> tid=3DVG_(get_current_tid)();
> a=3DVG_(get_EIP)(tid);
> if (VG_(get_fnname_if_entry)(a, name, 100)){
> VG_(printf) ("-> Entering %s :)\n",name);
> } else {
> VG_(printf) ("-> oh no\n");
> }
> }
Why are you calling get_fnname_if_entry in the helper again? There's no nee=
d=20
to do this: for a given basic block, debug info won't change in the course =
of=20
a program run.
Am Mittwoch, 31. Dezember 2003 15:02 schrieb Nick:
> > As Julian said, function calls are sometimes done by JMP or PUSH/RET
> > (runtime linker), and there are setjmp/longjmp and C++ exceptions,
> > unwinding multiple stack frames with a ESP write. Besides, I'm sure the=
re
> > are functions with multiple entry points.
>
> Well, a program making a call to a function in a dynamically linked libra=
ry
> would be an x86 CALL to the PLT section of that program's binary, wouldn't
Yes. But as PLT entries don't export any symbols and have no line debug inf=
o,
you will get never get any information from get_fnname_if_entry for=20
instructions in PLT sections.
=46rom the PLT section, there will be a JMP either into the runtime linker =
or in=20
into the requested function (on further calls)...
> it? If so would this mean my "give output before and after a CALL" is
> always correct for detecting function calls and returns within a particul=
ar
> binary? Or does valgrind translate the asm into something different? :)
As I said above, your printAfterCall is never called. You would have to pla=
ce=20
this at the beginning of the instrumentated version of the basic block=20
following the CALL instruction, but instrumentation of this basic block wil=
l=20
be done probably much later in time, perhaps never.
Josef
|
|
From: Nick <ni...@sa...> - 2003-12-31 03:02:35
|
> As Julian said, function calls are sometimes done by JMP or PUSH/RET (runtime > linker), and there are setjmp/longjmp and C++ exceptions, unwinding multiple > stack frames with a ESP write. Besides, I'm sure there are functions with > multiple entry points. Well, a program making a call to a function in a dynamically linked library would be an x86 CALL to the PLT section of that program's binary, wouldn't it? If so would this mean my "give output before and after a CALL" is always correct for detecting function calls and returns within a particular binary? Or does valgrind translate the asm into something different? :) Nick |
|
From: Nick <ni...@sa...> - 2003-12-31 02:58:51
|
Hi, > (hope you all had a nice XMas :-) You too 8) > You are using VG_(get_fnname_if_entry)() only for the first instruction of > every basic block. I'm not quite sure this is always correct. Does it work if > you check at every instruction? Given that it's incorrect, then that means that I'm getting less than or equal to the amount of calls to the code added during instrumentation that I should. But I haven't seen evidence of that yet. Nevertheless, I'll do as you suggest. > > I've had a go at using dyninst for this (www.dyninst.org), but it's very > > experimental and we had limited success getting it to compile and run on > > our various systems (Various versions of Redhat and Debian). > > Doesn't have dyninst the same problems as it is manipulating instructions > directly, too? It was a while ago that I played around with dyninst - I'll try to track down the results I got. I seem to remember them looking sensible. > To locate the multiple "CALL from a", it can help to print instruction > addresses and compare with the disassembled code, and use --tracegen=10100. I mentioned this to Julian Seward yesterday: """ I got the idea yesterday of enclosing CALLs with debugging statements, so I wouldn't have to deal with the 99 different RETs as you said ;) VG_(call_helper_0_0)(newCb, (Addr) &printBeforeCall); VG_(copy_UInstr)(newCb, u); VG_(call_helper_0_0)(newCb, (Addr) &printAfterCall); However, I still can't figure out what the heck is going on. printAfterCall never gets called, for one. """ shouldn't a function return (by whatever message) result in the instruction following the call being executed? I tried the following code on this toy program: //---------------------------- #include <stdio.h> void a(); int b(); int main(){ a(); b(); return 0; } void a(){ printf("hi\n"); } int b(){ printf("bye\n"); return 1; } //---------------------------- main() containing 804834c: e8 0c 00 00 00 call 804835d <a> 8048351: e8 1f 00 00 00 call 8048375 <b> but from the output below, printAfterCall() isn't reached. //---------------------------- #include "vg_skin.h" char name[100]; char file[100]; char line[100]; VG_DETERMINE_INTERFACE_VERSION void printName(void){ Addr a; ThreadId tid; tid=VG_(get_current_tid)(); a=VG_(get_EIP)(tid); if (VG_(get_fnname_if_entry)(a, name, 100)){ VG_(printf) ("-> Entering %s :)\n",name); } else { VG_(printf) ("-> oh no\n"); } } void printBeforeCall(void){ VG_(printf) ("-> Going to call\n"); } void printAfterCall(void){ VG_(printf) ("-> After call\n"); } void SK_(pre_clo_init)(void){ VG_(details_name) ("Foo"); VG_(details_version) ("0.0.1"); VG_(details_description) ("an example Valgrind skin"); VG_(details_copyright_author)( "Copyright (C) 2002-2003, Nick Seow."); VG_(details_bug_reports_to) ("nowhere"); VG_(register_compact_helper)((Addr) & printName); VG_(register_compact_helper)((Addr) & printBeforeCall); VG_(register_compact_helper)((Addr) & printAfterCall); } void SK_(post_clo_init)(void){ } void SK_(fini)(exitcode) { } UCodeBlock* SK_(instrument)(UCodeBlock* cb, Addr a){ UCodeBlock *newCb; Int i; UInstr* u; newCb=VG_(setup_UCodeBlock)(cb); if (VG_(get_fnname_if_entry)(a, name, 100)){ VG_(call_helper_0_0)(newCb, (Addr) & printName); } for (i = 0; i < VG_(get_num_instrs)(cb); i++) { u = VG_(get_instr)(cb, i); if (((u->opcode) == JMP) && ((u->jmpkind)==JmpCall) ) { VG_(call_helper_0_0)(newCb, (Addr) &printBeforeCall); VG_(copy_UInstr)(newCb, u); VG_(call_helper_0_0)(newCb, (Addr) &printAfterCall); } else VG_(copy_UInstr)(newCb, u); } VG_(free_UCodeBlock)(cb); return newCb; } //--------------------------------- <insert a bunch of stuff preceding main> -> Entering main :) -> Going to call -> Entering a :) -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _dl_lookup_versioned_symbol :) -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _IO_printf :) -> Going to call -> Going to call -> Entering _IO_vfprintf :) -> Going to call -> Going to call -> Entering __errno_location :) -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _dl_lookup_versioned_symbol :) -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _IO_flockfile :) -> Going to call -> Going to call -> Entering _IO_file_xsputn :) -> Going to call -> Going to call -> Entering _IO_file_overflow :) -> Going to call -> Going to call -> Entering _IO_doallocbuf :) -> Going to call -> Going to call -> Entering _IO_file_doallocate :) -> Going to call -> Going to call -> Entering _IO_file_stat :) -> Going to call -> Entering __fxstat64 :) -> Going to call -> Going to call -> Entering __errno_location :) -> Going to call -> Going to call -> Entering mmap :) -> Going to call -> Entering _IO_setb :) -> Going to call -> Going to call -> Entering _IO_do_write :) -> Going to call -> Entering _IO_default_xsputn :) -> Going to call -> Entering _IO_file_overflow :) -> Going to call -> Going to call -> Entering _IO_file_overflow :) -> Going to call -> Going to call -> Entering _IO_file_overflow :) -> Going to call -> Going to call -> Entering _IO_do_write :) -> Going to call -> Going to call -> Going to call -> Entering _IO_file_write :) -> Going to call -> Entering __libc_write :) -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _dl_lookup_versioned_symbol :) -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Going to call -> Entering _IO_funlockfile :) -> Going to call -> Going to call -> Entering b :) <et cetera> |
|
From: Josef W. <Jos...@gm...> - 2003-12-31 02:14:03
|
Hi, (hope you all had a nice XMas :-) Am Mittwoch, 24. Dezember 2003 03:45 schrieb Nicholas Seow: > > Josef Wiedendorfer is the real guru here as I think kcachegrind/calltree > > manages to track calls/returns. I'm sure he can elaborate. > > Ah. He's the one who originally suggested to me that it might be a linkage > gotcha. I'd been digging through the calltree code to try and find out how > it deals with this, but I've had little success groking it so far. Hmm, I should clean up and comment the code... You are using VG_(get_fnname_if_entry)() only for the first instruction of every basic block. I'm not quite sure this is always correct. Does it work if you check at every instruction? As Julian said, function calls are sometimes done by JMP or PUSH/RET (runtime linker), and there are setjmp/longjmp and C++ exceptions, unwinding multiple stack frames with a ESP write. Besides, I'm sure there are functions with multiple entry points. In calltree, I unconditionally need a call to a helper function at start of every basic block, and so I am doing a lot of things dynamically which perhaps could be done once at instrumentation time. This isn't the best solution efficiency-wise, but fairly robust. To locate the multiple "CALL from a", it can help to print instruction addresses and compare with the disassembled code, and use --tracegen=10100. > I've had a go at using dyninst for this (www.dyninst.org), but it's very > experimental and we had limited success getting it to compile and run on > our various systems (Various versions of Redhat and Debian). Doesn't have dyninst the same problems as it is manipulating instructions directly, too? Cheers, Josef |