|
From: Rex W. <wa...@gm...> - 2005-04-21 17:52:23
|
Hi I tried using VG_(describe_addr) and it returns a value (null) for every address. I have included VG_(needs_data_syms) in SK_(pre_clo_init). So instead I used VG_(get_fnname_if_entry) and it returns function names wherever it can. With this I can grep for my symbol names which matter to me (these names I can get by doing "nm a.out") . THe limitation with this is that I can only get symbol names that are static or global, and for arrays only that of the beginning address. I have no idea why VG_(describe_addr) gives me "(null)" for every addr. Anyway I am happy with atleast some data which I needed, and I am working on how to get names of symbols which are local ... any ideas? I was thinking, checking for Scope and trying something of that sort ... I was interested in callgrind but I could not find it in valgrind-2.4.0 so I tried downloading the latest source code snapshot using cvs but I was not able to login anonymously. It asks for a password and I have tried blank, "anoncvs" , "anonymous" but i am not able to login. I have followed whatever instruction is given on the valgrind website. Thanks.=20 Vikas >=20 > Message: 6 > From: Josef Weidendorfer <Jos...@gm...> > To: val...@li... > Subject: Re: [Valgrind-developers] Dullard with 2.4.0 > Date: Thu, 21 Apr 2005 17:49:41 +0200 >=20 > On Thursday 21 April 2005 15:24, Nicholas Nethercote wrote: > > On Thu, 21 Apr 2005, Rex Walburn wrote: > > > My aim is that I want to know which variables have been accessed and > > > written to or modified and how many times in a particular area of the > > > ... > > "variable"? What about compound structures like arrays and struct -- a= re > > they a single variable or do you consider the individual elements as > > variables? What about stack vs. static vs. heap-allocated variables? > > Etc. >=20 > One other problem is the amount of statistics data produced if there are = many > instances of data of same type. It probably makes sense to relate to data > types. >=20 > > I see. AIUI the symbol table handles code addresses, eg. function name= s, > > but not variable names. Variable names are in the debugging informatio= n. >=20 > Static data objects are also in the symbol table. See manual page of "nm"= for > symbol types. These are usually skipped in Valgrinds symbol reader, unles= s > VG_(needs_data_syms)() is called. The type information of symbols will be > found in the debug info. >=20 > IMHO there should be a hook for tools to be able to collect data symbol > information [This was the crappy patch I send some time ago ;-) ]. > Calling VG_(describe_addr)() at every memory access is probably way to sl= ow. >=20 > Josef >=20 > > Local variables on the stack are going to be tricky to deal with, since > > you'll have to identify when you're entering/exiting functions, which i= s > > harder than it first seems. > > > > > What did you mean by source-level instrumentation ? > > > > A bit like the source code parsing/data flow analysis that you mentione= d > > -- add instrumentation to the original source code, which would require > > parsing the source code, and some static analysis. Then you would run = the > > program and get the stats. > > > > N > > > > |
|
From: Stephen M.
|
JF> Rex Walburn wrote: RW> Hi RW> I tried using VG_(describe_addr) and it returns a value (null) for RW> every address. >>>>> "JF" == Jeremy Fitzhardinge <je...@go...> writes: JF> Only the stabs reader extracts enough type information for JF> describe_addr to work; nobody has put the effort into the DWARF JF> reader yet. If you compile with -gstabs, you might get more JF> useful results (though I suspect this code has been untested for a JF> while, so you may get some explosions instead). You might also want to try looking at the "Kvasir" tool that our research group has implemented. We had a similar problem of wanting to have detailed variable information along with per-instruction operation tracking: in our case, we wanted to print the values of all the accessible variables at the entrance and exit of functions, but to use Memcheck's information to know which memory locations had valid data. Rather than building on Valgrind's existing debugging information reading code, we made our own by modifying the "readelf" tool from the GNU Binutils (unfortunately, we didn't find out about libdwarf until too late); this just supports DWARF, but we read all sorts of information about global variables, parameters, arrays, and structs. We use this information to find the address(es) for each variable we're interested in, and then print their contents. You can get the source for Kvasir as part of the Daikon distribution, from http://pag.csail.mit.edu/daikon/download/. At the moment, it comes as a tool along with a minimally modified version of Valgrind 2.2.0, and includes hacked versions of Memcheck and readelf inside (it's all GPLed). In the current version, the code for reading the debugging information, traversing the sets of variables, and printing out their contents in our specific trace format aren't as well separated as we'd like, but if you don't mind reusing by cut and paste, you might find a lot of code you could take advantage of. -- Stephen |
|
From: Josef W. <Jos...@gm...> - 2005-04-24 18:02:03
|
On Friday 22 April 2005 15:48, Rex Walburn wrote: > Hi > You had mentioned the macro CALLGRIND_START_INSTRUMENTATION that can > be used to start instrumentation at a particular point in the source > code. So can I use this same macro for another tool like "dullard" > which dumps out memory traces for an executable ? Sorry, no. This macro will be ignored when run with a Valgrind tool other than callgrind. You would have to add similar support to Dullard. But perhaps it would be good to generalize this for all tools: A tool with different instrumentation levels should be able to specify this to Valgrind core, which will handle all the rest, i.e. flush the translation cache on a change. Neverless, "dullard" would have to be changed to support such an Valgrind extension. Josef > > THanks > Rex |
|
From: Rex W. <wa...@gm...> - 2005-04-24 21:52:12
|
THanks. that is all I wanted to know. I wanted to know if the same principle used in callgrind could be used for dullard. THanks again. Rex. On 4/24/05, Josef Weidendorfer <Jos...@gm...> wrote: > On Friday 22 April 2005 15:48, Rex Walburn wrote: > > Hi > > You had mentioned the macro CALLGRIND_START_INSTRUMENTATION that can > > be used to start instrumentation at a particular point in the source > > code. So can I use this same macro for another tool like "dullard" > > which dumps out memory traces for an executable ? >=20 > Sorry, no. > This macro will be ignored when run with a Valgrind tool other than callg= rind. > You would have to add similar support to Dullard. > But perhaps it would be good to generalize this for all tools: A tool wit= h > different instrumentation levels should be able to specify this to Valgri= nd > core, which will handle all the rest, i.e. flush the translation cache on= a > change. Neverless, "dullard" would have to be changed to support such an > Valgrind extension. >=20 > Josef >=20 > > > > THanks > > Rex > |
|
From: Rex W. <wa...@gm...> - 2005-04-27 19:10:56
|
Hi
Thanks for the info on Kvasir/Daikon but I have one fundamental
question. How do you detect local variables for a function ? I have
looked at Kvasir and cannot figure out where it does that. Given an
object file or an executable in Dwarf /Elf format is there any way to
list the local variables in a function ? I have looked at dwarfdump
and readelf output and they seem to stick to giving details of the
global symbols. The local variables, (which are kept on the stack),
are not shown. Is there a way to figure this out ? For example in the
function below,' i' is a local variable which is always on the stack.
I wanted to know if there is some part of code in Kvasir/(anywhere)
that can map a stack address to a local variable in the current scope?
I hope my question is clear.
main()=20
{
int i =3D0;
for(i=3D0;i<1;i++)
printf("%d\n",i);
}
Looking forward to your reply.
Thanks.
Rex
On 4/21/05, Stephen McCamant <sm...@cs...> wrote:
> JF> Rex Walburn wrote:
>=20
> RW> Hi
> RW> I tried using VG_(describe_addr) and it returns a value (null) for
> RW> every address.
>=20
> >>>>> "JF" =3D=3D Jeremy Fitzhardinge <je...@go...> writes:
>=20
> JF> Only the stabs reader extracts enough type information for
> JF> describe_addr to work; nobody has put the effort into the DWARF
> JF> reader yet. If you compile with -gstabs, you might get more
> JF> useful results (though I suspect this code has been untested for a
> JF> while, so you may get some explosions instead).
>=20
> You might also want to try looking at the "Kvasir" tool that our
> research group has implemented. We had a similar problem of wanting to
> have detailed variable information along with per-instruction
> operation tracking: in our case, we wanted to print the values of all
> the accessible variables at the entrance and exit of functions, but to
> use Memcheck's information to know which memory locations had valid
> data.
>=20
> Rather than building on Valgrind's existing debugging information
> reading code, we made our own by modifying the "readelf" tool from the
> GNU Binutils (unfortunately, we didn't find out about libdwarf until
> too late); this just supports DWARF, but we read all sorts of
> information about global variables, parameters, arrays, and structs.
> We use this information to find the address(es) for each variable
> we're interested in, and then print their contents.
>=20
> You can get the source for Kvasir as part of the Daikon distribution,
> from http://pag.csail.mit.edu/daikon/download/. At the moment, it
> comes as a tool along with a minimally modified version of Valgrind
> 2.2.0, and includes hacked versions of Memcheck and readelf inside
> (it's all GPLed). In the current version, the code for reading the
> debugging information, traversing the sets of variables, and printing
> out their contents in our specific trace format aren't as well
> separated as we'd like, but if you don't mind reusing by cut and
> paste, you might find a lot of code you could take advantage of.
>=20
> -- Stephen
>
|
|
From: Tom H. <to...@co...> - 2005-04-27 19:59:59
|
In message <792...@ma...>
Rex Walburn <wa...@gm...> wrote:
> Thanks for the info on Kvasir/Daikon but I have one fundamental
> question. How do you detect local variables for a function ? I have
> looked at Kvasir and cannot figure out where it does that. Given an
> object file or an executable in Dwarf /Elf format is there any way to
> list the local variables in a function ? I have looked at dwarfdump
> and readelf output and they seem to stick to giving details of the
> global symbols. The local variables, (which are kept on the stack),
> are not shown. Is there a way to figure this out ? For example in the
> function below,' i' is a local variable which is always on the stack.
> I wanted to know if there is some part of code in Kvasir/(anywhere)
> that can map a stack address to a local variable in the current scope?
> I hope my question is clear.
The output of dwarfdump should show the location of stack variables
just fine - they will usually have a DW_OP_fbreg location expression.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Stephen M.
|
>>>>> "RW" == Rex Walburn <wa...@gm...> writes: RW> Hi RW> Thanks for the info on Kvasir/Daikon but I have one fundamental RW> question. How do you detect local variables for a function ? I RW> have looked at Kvasir and cannot figure out where it does RW> that. Given an object file or an executable in Dwarf /Elf format RW> is there any way to list the local variables in a function ? I RW> have looked at dwarfdump and readelf output and they seem to stick RW> to giving details of the global symbols. The local variables, RW> (which are kept on the stack), are not shown. Is there a way to RW> figure this out ? For example in the function below,' i' is a RW> local variable which is always on the stack. I wanted to know if RW> there is some part of code in Kvasir/(anywhere) that can map a RW> stack address to a local variable in the current scope? I hope my RW> question is clear. Kvasir doesn't include any code for accessing local variables, because for our application, we were just interested in global (and static) variables, parameters, and return values. As Tom Hughes points out, though, DWARF does include information about the location of locals, so I don't think they would be too hard to add. Locals will be either on the stack, where they can be treated much like Kvasir treats parameters, or they can be in registers; the debugging information will tell you which. At least in theory, you need to worry about the compiler moving values that correspond to the same variable between registers and stack slots; there's a way of representing this in DWARF2, I think. I couldn't get GCC (3.3, 3.4) to do this on a small example, though, so it may not be a problem in practice. Hope this helps, -- Stephen |
|
From: Jeremy F. <je...@go...> - 2005-04-21 17:56:09
|
Rex Walburn wrote:
>Hi
>I tried using VG_(describe_addr) and it returns a value (null) for
>every address.
>
>
Only the stabs reader extracts enough type information for describe_addr
to work; nobody has put the effort into the DWARF reader yet. If you
compile with -gstabs, you might get more useful results (though I
suspect this code has been untested for a while, so you may get some
explosions instead).
J
|