|
From: Mike L. <mik...@gm...> - 2017-02-25 02:55:53
|
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 |
|
From: Ivo R. <iv...@iv...> - 2017-03-02 21:28:50
|
2017-02-25 3:55 GMT+01:00 Mike Lui <mik...@gm...>: > 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. |
|
From: Mike L. <mik...@gm...> - 2017-03-02 22:07:58
|
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? Mike On Thu, Mar 2, 2017 at 4:28 PM Ivo Raisr <iv...@iv...> wrote: 2017-02-25 3:55 GMT+01:00 Mike Lui <mik...@gm...>: > 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. |
|
From: Ivo R. <iv...@iv...> - 2017-03-02 22:34:33
|
2017-03-02 23:07 GMT+01:00 Mike Lui <mik...@gm...>: > 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 |
|
From: Mike L. <mik...@gm...> - 2017-03-02 23:01:35
|
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 <iv...@iv...> wrote: > 2017-03-02 23:07 GMT+01:00 Mike Lui <mik...@gm...>: > > 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 > |
|
From: Ivo R. <iv...@iv...> - 2017-03-02 23:27:01
|
2017-03-03 0:01 GMT+01:00 Mike Lui <mik...@gm...>: > 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. |