generating pretty and/or less system-intensive measuring-points - c

Question

I work with C and I make apache modules and I work with strace as my main tool for debugging timings. Here's code I threw together. My apologies if variable names do not meet standards.
#include <stdio.h>
int main(){
long ct2,ct; //counters
int a=0; //dummy value
FILE *f0=fopen("/","r"); //measuring point
ct2=10;
while (--ct2>0){
ct=5000000;
while (--ct>0){
if (!!a){
printf("%d",a);
}
}
}
FILE *f=fopen("/","r"); //measuring point
ct2=10;
while (--ct2>0){
ct=5000000;
while (--ct>0){
if (a){
printf("%d",a);
}
}
}
FILE *f2=fopen("/","r"); //measuring point
return 0;
}
This code does compile. I then run it through strace (by typing in a terminal: strace -r -ttt ./a.out) and I see:
0.000000 execve("./a.out", ["./a.out"], [/* 47 vars */]) = 0
0.000315 brk(0) = 0x804a000
0.000124 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
0.000144 open("/etc/ld.so.cache", O_RDONLY) = 3
0.000116 fstat64(3, {st_mode=S_IFREG|0644, st_size=139721, ...}) = 0
0.000138 mmap2(NULL, 139721, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ece000
0.000114 close(3) = 0
0.000109 open("/lib/libc.so.6", O_RDONLY) = 3
0.000113 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360d\1"..., 512) = 512
0.000130 fstat64(3, {st_mode=S_IFREG|0755, st_size=1575187, ...}) = 0
0.000131 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ecd000
0.000122 mmap2(NULL, 1357360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d81000
0.000119 mmap2(0xb7ec7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x146) = 0xb7ec7000
0.000146 mmap2(0xb7eca000, 9776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eca000
0.000139 close(3) = 0
0.000112 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d80000
0.000119 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d806c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
0.000217 mprotect(0xb7ec7000, 4096, PROT_READ) = 0
0.000108 munmap(0xb7ece000, 139721) = 0
0.000174 brk(0) = 0x804a000
0.000099 brk(0x806b000) = 0x806b000
0.000110 open("/", O_RDONLY) = 3
0.203487 open("/", O_RDONLY) = 4
0.202225 open("/", O_RDONLY) = 5
0.000133 exit_group(0) = ?
I can tell right off at the end that:
0.000110 open("/", O_RDONLY) = 3
0.203487 open("/", O_RDONLY) = 4
0.202225 open("/", O_RDONLY) = 5
return to the three measuring points I set up.
I want to be able to adjust the measuring point lines in my code so that when I run strace I can find my measuring points like I do now, but where the system makes less intensive operations. I don't see anything else from strace related to my program other than the file calls.
I'm thinking maybe if there was such a thing as a built-in MeasureMe function in C that I would use that in place of the measuring point lines in my code, then strace could output:
0.000110 MeasureMe called in code
0.203487 MeasureMe called in code
0.202225 MeasureMe called in code
Is there any way I can go about this with Strace?
The reason why I'm asking about strace instead of gdb is because I use it to debug requests to my apache server like the person in this video does it, and I'll be able to see apache modules in action:
https://www.youtube.com/watch?v=eF-p--AH37E
Any idea how I can solve this? or will I have to continue to make failed attempts at opening non-existing files?

Answer 1

I gather what you are currently using is open("/",O_RDONLY) [or open("/i_do_not_exist",O_RDONLY)] for a "tracepoint". Unfortunately, because you're using strace, you're constrained to using syscalls. But, there is a way to achieve the effect you want.
What you need/want for a tracepoint that you're manually inserting at various points in your source code is:
Any unique syscall that doesn't harm anything
Is easily distinguishable from real code [even code that may return errors such as opening a file or checking for existence with access]
Minimal overhead / fastest execution
Actually, dup on a bad fildes fills the bill nicely:
dup(-10000);
It will return EBADF. It is easily distinguishable as a tracepoint because most real dup calls that are "bad" will be dup(-1)
You can have as many of these as you want. The actual argument becomes the "tracepoint number":
dup(-10001); // tracepoint 1
...
dup(-10002); // tracepoint 2
...
dup(-10003); // tracepoint 3
The output will look like:
0.000044 dup(-10001) = -1 EBADF (Bad file descriptor)
0.000022 dup(-10002) = -1 EBADF (Bad file descriptor)
0.000019 dup(-10003) = -1 EBADF (Bad file descriptor)
I usually encapsulate this in a macro:
#ifdef DEBUG
#define TRACEPOINT(_tno) tracepoint(_tno)
#else
#define TRACEPOINT(_tno) /**/
#endif
void
tracepoint(int tno)
{
dup(-10000 - tno);
}
Then, I add something like:
TRACEPOINT(1); // initialization phase
...
TRACEPOINT(2); // execution phase
...
TRACEPOINT(3); // cleanup/shutdown
Now, I'll write a perl or python script to read in the source files, extracting the comments for the given tracepoints, and append them to the matching lines in the strace output file:
0.000044 TRACEPOINT(1) initialization phase
0.000022 TRACEPOINT(2) execution phase
0.000019 TRACEPOINT(3) cleanup/shutdown
A more sophisticated version of the post-processing script can do all sorts of things:
keep track of timestamps and append a time difference between one tracepoint and the previous one to the trace line
add file name and line number information to the tracepoint lines
keep track of the number of times a given tracepoint is hit [similar to gdb and breakpoints]
generate summary reports relating to tracepoints