|
From: Adarsh Y. <ay...@um...> - 2010-04-27 21:57:41
|
Hi,
I am trying to create the tool for predicting return address in Valgrind.
All I am doing now is just adding temporary code to the cachegrind tool to
recognize function calls and return events and act accordingly.
The changes are very minimal. But when i run it I am getting an error which
says that the "Impossible happened!!" and the VEX temporary storage has been
exhausted.
Could someone let me know if you have any idea what this error is about and
maybe some pointers on how to go about solving it.
The error being reported:
VEX temporary storage exhausted.
Pool = TEMP, start 0x383353d0 curr 0x386f542c end 0x38705ccf (size 4000000)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 526792 bytes allocated
vex storage: P total 288 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==18961== at 0x3800A3C5: report_and_quit (m_libcassert.c:191)
==18961== by 0x3800A42B: panic (m_libcassert.c:275)
==18961== by 0x3800A47D: vgPlain_core_panic_at (m_libcassert.c:280)
==18961== by 0x3800A498: vgPlain_core_panic (m_libcassert.c:285)
==18961== by 0x380235E6: failure_exit (m_translate.c:674)
==18961== by 0x380A87DE: vpanic (main_util.c:237)
==18961== by 0x380A8EE0: private_LibVEX_alloc_OOM (main_util.c:182)
==18961== by 0x380ACFAD: addStmtToIRSB (libvex.h:310)
==18961== by 0x38001394: flushEvents (cg_main.c:828)
==18961== by 0x38001E38: cg_instrument (cg_main.c:1236)
==18961== by 0x380A704B: LibVEX_Translate (main_main.c:528)
==18961== by 0x38021055: vgPlain_translate (m_translate.c:1518)
==18961== by 0x38047FE8: vgPlain_scheduler (scheduler.c:857)
==18961== by 0x38072F98: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==18961== at 0xB1B357: _dl_start (in /lib/ld-2.5.so)
==18961== by 0xB1A816: ??? (in /lib/ld-2.5.so)
--
Adarsh Yoga
Graduate Student, Computer Science
Indiana University, Bloomington
|
|
From: Julian S. <js...@ac...> - 2010-04-28 06:03:32
|
On Tuesday 27 April 2010, Adarsh Yoga wrote: > Hi, > > I am trying to create the tool for predicting return address in Valgrind. > All I am doing now is just adding temporary code to the cachegrind tool to > recognize function calls and return events and act accordingly. > The changes are very minimal. But when i run it I am getting an error which > says that the "Impossible happened!!" and the VEX temporary storage has > been exhausted. That sounds a bit unlikely, unless you have somehow allocated a very large number of IR objects during the translation. Or are instrumenting a very long basic block. What do your minimal changes look like? J |
|
From: Adarsh Y. <ay...@um...> - 2010-04-28 06:10:18
|
In the cg_instrument() function is cg_main() i have added the following code
to recognise function calls:
if (sbIn->jumpkind == Ijk_Call){
VG_(printf)("In jumpkind call\n");
//VG_(printf)(sbIn->jumpkind);
addEvent_Cl( &cgs, curr_inode, sbIn->next );
}
The function addEvent_Cl looks like this:
static
void addEvent_Cl ( CgState* cgs, InstrInfo* inode, IRAtom* whereTo )
{
Event* evt;
if (cgs->events_used == N_EVENTS) flushEvents(cgs);
evt = &cgs->events[cgs->events_used];
VG_(printf)("In add eventCl");
init_Event(evt);
evt->tag = Ev_Cl;
evt->inode = inode;
evt->Ev.Bi.dst = whereTo;
cgs->events_used++;
}
In flushEvents(cgs), i have added a case to add the helper function:
case Ev_Cl:
helperName = "log_Call";
helperAddr = &log_Call;
argv = mkIRExprVec_2( i_node_expr, ev->Ev.Bi.dst
);//ev->Ev.Bc.taken );
regparms = 2;
break;
On Wed, Apr 28, 2010 at 2:19 AM, Julian Seward <js...@ac...> wrote:
> On Tuesday 27 April 2010, Adarsh Yoga wrote:
> > Hi,
> >
> > I am trying to create the tool for predicting return address in Valgrind.
> > All I am doing now is just adding temporary code to the cachegrind tool
> to
> > recognize function calls and return events and act accordingly.
> > The changes are very minimal. But when i run it I am getting an error
> which
> > says that the "Impossible happened!!" and the VEX temporary storage has
> > been exhausted.
>
> That sounds a bit unlikely, unless you have somehow allocated a very
> large number of IR objects during the translation. Or are instrumenting
> a very long basic block. What do your minimal changes look like?
>
> J
>
--
Adarsh Yoga
Graduate Student, Computer Science
Indiana University, Bloomington
|
|
From: Adarsh Y. <ay...@um...> - 2010-04-29 06:32:14
|
Hi All,
I am new to Valgrind. I am trying to write a tool to predict the return
address. I have read the documentation regarding writing a new tool. So all
my preliminary work is set. I am recognizing the calls and the returns with
the jumpkind property for the input block which will be either set to
Ijk->Call in the case of a call or Ijk->return for a return statement.
I initially tried a small input program for my tool. I noticed that the
number of calls is not equal to the number of returns. Also, in my input
program all I am doing is calling foo() from main(). But when I checked for
the number of calls it is returning something in the range of 600-700 calls.
The returns too are not matching the number of calls. Am I missing anything
fundamental here with respect to the IR representation?
Regards,
Adarsh
PS: The input program is,
#include<stdio.h>
void foo(int);
main ()
{
foo(15);
}
void foo(int arg)
{
//i=arg;
if (arg!=0){foo(arg-1);}
printf("In function foo");
}
|
|
From: Adarsh Y. <ay...@um...> - 2010-04-29 22:47:08
|
Is there a way to obtain the address of the instruction to which a return
instruction jumps to? I know this is being done in Callgrind but i am not
able to figure out how.
On Thu, Apr 29, 2010 at 5:56 AM, Josef Weidendorfer <
Jos...@gm...> wrote:
> On Thursday 29 April 2010, Adarsh Yoga wrote:
> > I am new to Valgrind. I am trying to write a tool to predict the return
> > address. I have read the documentation regarding writing a new tool. So
> all
> > my preliminary work is set. I am recognizing the calls and the returns
> with
> > the jumpkind property for the input block which will be either set to
> > Ijk->Call in the case of a call or Ijk->return for a return statement.
> >
> > I initially tried a small input program for my tool. I noticed that the
> > number of calls is not equal to the number of returns.
>
> So you solved your previous problem?
>
> > Also, in my input
> > program all I am doing is calling foo() from main(). But when I checked
> for
> > the number of calls it is returning something in the range of 600-700
> calls.
>
> Usually, there is a lot of code run before even entering main(), such as
> initializing shared libraries and so on. So the number sound fine.
>
>
> > The returns too are not matching the number of calls. Am I missing
> anything
> > fundamental here with respect to the IR representation?
>
> You have to be aware that VEX usually generates superblocks, chasing
> over CALL instructions (as these are effectively unconditional jumps), so
> you
> will miss them. You can set
>
> VG_(clo_vex_control).guest_chase_thresh = 0;
>
> to forbid this. Then, your calls and returns should be more similar ;-)
>
> Another thing is that the jumpkind you are using is quite precise for
> x86/x86_64
> architectures, but for PPC this is more an assumption by VEX, as PPC does
> not have explicit CALL instructions.
>
> Josef
>
> >
> > Regards,
> > Adarsh
> >
> > PS: The input program is,
> > #include<stdio.h>
> >
> > void foo(int);
> > main ()
> > {
> > foo(15);
> > }
> >
> > void foo(int arg)
> > {
> > //i=arg;
> > if (arg!=0){foo(arg-1);}
> > printf("In function foo");
> > }
> >
>
>
>
--
Adarsh Yoga
Graduate Student, Computer Science
Indiana University, Bloomington
|