Quantcast

Clarification on functions in pub_tool_tooliface.h

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Clarification on functions in pub_tool_tooliface.h

Mike Lui
Being unable to search through gmane for now, I turn to the users group.

I'd like some clarification regarding some functions I'm seeing in the tool interface.

  • track_new_mem_startup
  • ....
  • track_new_mem_mmap
  • ...
  • track_pre_mem_read
  • track_pre_mem_write
  • track_post_mem_write
  • track_post_reg_write
These callbacks specifically refer to events within the core, right? Does this mean that they bear no relevance to profiling the user application?

Am I correct that a "mem_write" callback only gets called for memory write that happens during translation, internal signal handling, etc, along with the "new_mmap" calls? If I were to instrument the application under test then I'd go through the callback given in "basic_tool_funcs", correct?

I only asks because I just noticed these functions, and the wording in the comments wasn't incredibly clear.

Thanks,
Mike


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clarification on functions in pub_tool_tooliface.h

iraisr
2017-02-25 3:55 GMT+01:00 Mike Lui <[hidden email]>:

> Being unable to search through gmane for now, I turn to the users group.
>
> I'd like some clarification regarding some functions I'm seeing in the tool
> interface.
>
> track_new_mem_startup
> ....
> track_new_mem_mmap
> ...
> track_pre_mem_read
> track_pre_mem_write
> track_post_mem_write
> track_post_reg_write
>
> These callbacks specifically refer to events within the core, right? Does
> this mean that they bear no relevance to profiling the user application?
>
> Am I correct that a "mem_write" callback only gets called for memory write
> that happens during translation, internal signal handling, etc, along with
> the "new_mmap" calls? If I were to instrument the application under test
> then I'd go through the callback given in "basic_tool_funcs", correct?
>
> I only asks because I just noticed these functions, and the wording in the
> comments wasn't incredibly clear.

Did you get any response for your query? If not, I will chime in.
I.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clarification on functions in pub_tool_tooliface.h

Mike Lui
Hi Ivo,

I didn't get a response, but I found a snippet in the original paper:

Table 1 says these functions are only for syscalls and the valgrind core. Is that still correct?

Mike

On Thu, Mar 2, 2017 at 4:28 PM Ivo Raisr <[hidden email]> wrote:
2017-02-25 3:55 GMT+01:00 Mike Lui <[hidden email]>:
> Being unable to search through gmane for now, I turn to the users group.
>
> I'd like some clarification regarding some functions I'm seeing in the tool
> interface.
>
> track_new_mem_startup
> ....
> track_new_mem_mmap
> ...
> track_pre_mem_read
> track_pre_mem_write
> track_post_mem_write
> track_post_reg_write
>
> These callbacks specifically refer to events within the core, right? Does
> this mean that they bear no relevance to profiling the user application?
>
> Am I correct that a "mem_write" callback only gets called for memory write
> that happens during translation, internal signal handling, etc, along with
> the "new_mmap" calls? If I were to instrument the application under test
> then I'd go through the callback given in "basic_tool_funcs", correct?
>
> I only asks because I just noticed these functions, and the wording in the
> comments wasn't incredibly clear.

Did you get any response for your query? If not, I will chime in.
I.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clarification on functions in pub_tool_tooliface.h

iraisr
2017-03-02 23:07 GMT+01:00 Mike Lui <[hidden email]>:
> Hi Ivo,
>
> I didn't get a response, but I found a snippet in the original paper:
> https://www.cs.columbia.edu/~junfeng/09fa-e6998/papers/valgrind.pdf
>
> Table 1 says these functions are only for syscalls and the valgrind core. Is
> that still correct?

Hi Mike,

As comment on line 517 in pub_tool_tooliface.h says, these are
callback functions
which the Valgrind core (framework) use to pass various events to the
analysis tool.
Tool can be one of memcheck, helgrind, drd, cachegrind, callgrind,
massif, ... [1]
Various tools are interested in slightly different events, so they do
or don't register
event callbacks. Syscall is just one type of such an event.

> callbacks specifically refer to events within the core, right?
>> > Does this mean that they bear no relevance to profiling the user application?

User application usually does not interact with these events.
What are you trying to achieve? What is your goal? Asking too detailed question
without knowing the context (what are you up to) does not usually lead to
meaningful answers.

>> > Am I correct that a "mem_write" callback only gets called for memory
>> > write that happens during translation, internal signal handling, etc, along
>> > with the "new_mmap" calls?

Nope. pre_mem_write and post_mem_write are callbacks for events emited
by Valgrind core (framework) when it intercepted a syscall on behalf
of the application.
Because Valgrind has no idea what is happening during a syscall inside kernel,
this is described by so called "syscall wrappers". They tend to describe things
such as "this particular piece of memory is going to be written to  by
kernel during syscall (pre_mem_write)"
and "this particular piece of memory was written to by kernel during
syscall (post_mem_write)".

>  If I were to instrument the application under test then I'd go through the callback given in "basic_tool_funcs", correct?

Instrumentation happens automatically, depending on the analysis tool
selected at Valgrind startup.
I recommend you to read Valgrind intro [1] and core [2], at least the
initial part.

I.

[1] http://valgrind.org/docs/manual/manual-intro.html
[2] http://valgrind.org/docs/manual/manual-core.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clarification on functions in pub_tool_tooliface.h

Mike Lui
I did a poor job explaining my inquiry. I'm writing a valgrind tool that's tracking the IOPS/FLOPS/reads/writes reported by VEX IR during instrumentation, and doing some minor analysis on the IR with a instrument_basic_block callback (as documented in  http://www.valgrind.org/docs/manual/writing-tools.html )

I was interested how to also see which data was written to by any syscalls (not to instrument syscalls), and saw the aforementioned callbacks in pub_tool_tooliface.h
After reading the comments, my confusion was whether registering a callback to (*_mem_write) would instrument ALL memory operations (rendering my instrument_basic_block unnecessary for processing writes). 

So my understanding right now is that as long as a syscall wrapper exists, registering to *_mem_write will give me metadata about userspace memory modified by supported syscalls, otherwise I use the normal instrument_basic_block callback. Because I'm not currently interested in events that happen within the core framework (besides thread swapping, which I already detect with VG_(get_running_tid)), I wouldn't need to register to other aforementioned callbacks.



On Thu, Mar 2, 2017 at 5:34 PM Ivo Raisr <[hidden email]> wrote:
2017-03-02 23:07 GMT+01:00 Mike Lui <[hidden email]>:
> Hi Ivo,
>
> I didn't get a response, but I found a snippet in the original paper:
> https://www.cs.columbia.edu/~junfeng/09fa-e6998/papers/valgrind.pdf
>
> Table 1 says these functions are only for syscalls and the valgrind core. Is
> that still correct?

Hi Mike,

As comment on line 517 in pub_tool_tooliface.h says, these are
callback functions
which the Valgrind core (framework) use to pass various events to the
analysis tool.
Tool can be one of memcheck, helgrind, drd, cachegrind, callgrind,
massif, ... [1]
Various tools are interested in slightly different events, so they do
or don't register
event callbacks. Syscall is just one type of such an event.

> callbacks specifically refer to events within the core, right?
>> > Does this mean that they bear no relevance to profiling the user application?

User application usually does not interact with these events.
What are you trying to achieve? What is your goal? Asking too detailed question
without knowing the context (what are you up to) does not usually lead to
meaningful answers.

>> > Am I correct that a "mem_write" callback only gets called for memory
>> > write that happens during translation, internal signal handling, etc, along
>> > with the "new_mmap" calls?

Nope. pre_mem_write and post_mem_write are callbacks for events emited
by Valgrind core (framework) when it intercepted a syscall on behalf
of the application.
Because Valgrind has no idea what is happening during a syscall inside kernel,
this is described by so called "syscall wrappers". They tend to describe things
such as "this particular piece of memory is going to be written to  by
kernel during syscall (pre_mem_write)"
and "this particular piece of memory was written to by kernel during
syscall (post_mem_write)".

>  If I were to instrument the application under test then I'd go through the callback given in "basic_tool_funcs", correct?

Instrumentation happens automatically, depending on the analysis tool
selected at Valgrind startup.
I recommend you to read Valgrind intro [1] and core [2], at least the
initial part.

I.

[1] http://valgrind.org/docs/manual/manual-intro.html
[2] http://valgrind.org/docs/manual/manual-core.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Clarification on functions in pub_tool_tooliface.h

iraisr
2017-03-03 0:01 GMT+01:00 Mike Lui <[hidden email]>:
> I did a poor job explaining my inquiry. I'm writing a valgrind tool that's
> tracking the IOPS/FLOPS/reads/writes reported by VEX IR during
> instrumentation, and doing some minor analysis on the IR with a
> instrument_basic_block callback (as documented in
> http://www.valgrind.org/docs/manual/writing-tools.html)

That is interesting. How are you going to represent the results?
Cannot be the existing tools "persuaded" to do what you need?

> So my understanding right now is that as long as a syscall wrapper exists,
> registering to *_mem_write will give me metadata about userspace memory
> modified by supported syscalls, otherwise I use the normal
> instrument_basic_block callback.

Alright.

I.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Loading...