Hi, Thank you for reviewing the patch. But I need more discussion.
On Thu, 19 Sep 2013 18:05:06 -0700, Luca Clementi <[email protected]> wrote: ... >> Why delete_mmap_cache invocation is needed after wait related system calls? >> > > I can't find a logical explanation for that. > I think that part of the code should be removed as you indicated. O.k. Let's remove the code block. On Thu, 19 Sep 2013 18:05:06 -0700, Luca Clementi <[email protected]> wrote: > Although I have one minor comment. > Since we are printing the stack trace on return of a sys call, > shouldn't we update the mapping _before_ we print the stack trace? > In most of the situation it does not matter except for execve (we can > avoid a "backtracing_error"). > > I simply moved the delete_mmap_cache up in the trace_syscall_exiting: I think there is no difference between _after_ and _before_. Let's think about calling mmap then getpid. ** _after_ case ** -1. mmap run in kernel and the map of process is modified. 0. control for mmap syscall is returned from kernel, then 1. the stack for calling mmap is printed, then 2. the cache is cleared, then 3. getpid is called, then 4. cache is rebuilt (in print_stack), then 5. the stack for calling getpid is printed(in print_stack). Note: the map is refereed in 4 but between 0 and 5, the map for the process is not modified. ** _before_ case ** -1. mmap run in kernel and the map of process is modified. 0. control for mmap syscall is returned from kernel, then 1. the cache is cleared, then 2. cache is rebuilt (in print_stack), then 3. the stack for calling mmap is printed, then 4. getpid is called, then 5. the stack for calling getpid is printed using the cache built in 2. In the both case, when printing the stack trace for getpid, newer cache is used. As you wrote, execve is special. We are interested in the context of execve invoked. So we should capture the stack in `trace_syscall_entering'. After execve, the context is destroyed. ...However, I've found more important thing. libunwind scans /proc/$pid/maps every print_stacktrace invocation! If libunwind provides `unw_get_proc_name_and_path', the map cache management will not be needed in strace. I already submitted a conceptual patch: http://lists.nongnu.org/archive/html/libunwind-devel/2013-09/msg00009.html If `unw_get_proc_name_and_path' is introduced in libunwind, we can make unwind.c much simpler. Only the issues are when capturing the stack and when printing it. > To complete your patch it will require modification to all 25 > syscallent.h, correct? Yes. Masatake YAMATO ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
