lkml.org 
[lkml]   [2009]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: performance counter ~0.4% error finding retired instruction count

* Paul Mackerras <paulus@samba.org> wrote:

> I can think of three ways to eliminate the PLT resolver overhead on
> execvp:
>
> (1) Do execvp on a non-executable file first to get execvp resolved:
>
> char tmpnam[16];
> int fd;
> char *args[1];
>
> strcpy(tmpname, "/tmp/perfXXXXXX");
> fd = mkstemp(tmpname);
> if (fd >= 0) {
> args[1] = NULL;
> execvp(tmpname, args);
> close(fd);
> unlink(tmpname);
> }
> enable_counters();
> execvp(prog, argv);
>
> (2) Look up execvp in glibc and call it directly:
>
> int (*execptr)(const char *, char *const []);
>
> execptr = dlsym(RTLD_NEXT, "execvp");
> enable_counters();
> (*execptr)(prog, argv);
>
> (3) Resolve the executable path ourselves and then invoke the execve
> system call directly:
>
> char *execpath;
>
> execpath = search_path(getenv("PATH"), prog);
> enable_counters();
> syscall(NR_execve, execpath, argv, envp);
>
> (4) Same as (1), but rely on "" being an invalid program name for
> execvp:
>
> execvp("", argv);
> enable_counters();
> execvp(prog, argv);
>
> What do you guys think? Does any of these appeal more than the
> others? I'm leaning towards (4) myself.

(4) looks convincingly elegant.

We could also do (5): a one-shot counters-disabled ptrace run of the
target, then enable-counters-in-target + ptrace-detach after the
first stop.

Ingo


\
 
 \ /
  Last update: 2009-06-29 05:51    [W:0.097 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site