prettier function tracing
[ link: prettier-function-tracing | tags: code c | updated: Fri, 15 Jan 2010 22:28:18 ]
This is a follow up to my pretty function tracing article. I base this work on the code presented there.
Some one asked me how to get the gcc -finstrument-functions
feature working. If you don't know this
flag will modify the entry and exit to/from each function to make a call out to a special set of functions used
for tracing.
While I've read about this feature, I never actually tried it. So here is what I learned...
portable printf
[ link: 20090625181315 | tags: c code | updated: Thu, 25 Jun 2009 18:49:19 ]
I was squashing some warnings in uzbl code:
printf("set %s = %d\n", (char *)k, (int)*c->ptr);
Ignoring the fact that, at first glance, it's weird to cast a pointer to int
(ptr
is defined as void**
), compiling this code on 64bit would warn you
that you were casting a pointer to an int. That's because a pointer is 64bit
and an int is 32bit.
popen with stdin, stdout, and stderr
[ link: popenRWE | tags: c code | updated: Mon, 08 Jun 2009 00:48:56 ]
I've look around for an open source implementation of popen()
that can handle redirection of
stdin, stdout, and stderr of the program executed. I was unable to find one, so I wrote
my own.
If you need to fork a helper process and maintain bidirectional communication wtih it, then you can use my popenRWE() (source: popenRWE.c.
Here is an example of how it might be used:
int pipe[3];
int pid;
const char *const args[] = {
"cat",
"-n",
NULL
};
pid = popenRWE(pipe, args[0], args);
// write to pipe[0] - input to cat
// read from pipe[1] - output from cat
// read from pipe[2] - errors from cat
pcloseRWE(pid, pipe);
Makefile template
[ link: makefile-template | tags: c code make | updated: Tue, 07 Aug 2007 11:30:08 ]
Someone on #oclug
was asking about building C programs with make. I wrote up this simple Makefile for him.
vim and linux CodingStyle
[ link: vim-and-linux-coding-style | tags: vim linux kernel c code | updated: Wed, 02 Sep 2009 14:14:46 ]
It would seem that either no one that codes for the Linux kernel does so under vim, or if they do they don't have the time to share their vim configuration that doesn't conflict with the kernel's CodingStyle.
Below I will discuss some changes I had to make to my .vimrc and .vim/c.vim to work with C efficiently.
C style
[ link: c-style | tags: code linux c | updated: Wed, 03 Jan 2007 10:20:54 ]
A new comer to my place of work was asking me how he can improve his code style. Here are some suggestions I had for him.
google-codesearch from vim
[ link: codesearch-from-vim | tags: vim google code | updated: Mon, 23 Jul 2018 09:34:53 ]
I just saw vim hint 1354 pop up in my RSS feed. It's a neat idea... but it's hard to decide what documentation should be looked up. Simply using the file type is insufficient.
It turns out that it's a lot more awesome to do google codesearch lookup on it.
tags/cscope for system headers
[ link: usr-include-tags | tags: code vim tags | updated: Fri, 20 Oct 2006 16:21:06 ]
I love tags files for in coding, and enjoy using the tag feature in vim as well as the derived tag-based completion. I do a lot of my development in the kernel, so all I usually have to do is put /usr/src/linux into my vim tags configuration.
Sometimes I have to do some user space hacking too, and I often forget all the names of glib and pthread library functions. Having a system wide tags file is very very useful. Below is a Makefile that I carry around with me and place in /usr/include to keep my system tags in sync.
pretty function tracing
[ link: pretty-function-tracing | tags: code c | updated: Thu, 20 Aug 2009 22:14:33 ]
I wanted to see how different functions got used in a block of code that I was new to... and was having a hard time understanding. My UML instance was acting flaky and didn't cooperate with gdb, so I could not single step the code.
I added a small chunk of C code to generate pretty tracing that looks like this:
,-< ipsec_sa_wipe:946
| ,-< ipsec_sa_put:549
| `-> ipsec_sa_put:561 = 0
`-> ipsec_sa_wipe:1054 = 0
Functions can nest upto 25 times (arbitrary max) and after that it stops indenting nicely. The code has to be modified so that at the entry of each block there is a call to the
IN
macro, and on the exit to the OUT
macro. Here is an example:
void
foo (void)
{
IN();
// something
OUT();
}
Have a look at the code.
I should probably hack something like this using systemtap or at least use jprobes for the tracing instead of modifying the source.
Related:
- a friend pointed me to gcc
-finstrument-functions
option that makes gcc generate calls to an arbitrary handler for each function entered and exited. - hrprof uses the
-finstrument-function
feature and extracts more information. - a bit more research revealed etrace which seems to do this kind of function tracing at run-time.
entropy injection
[ link: entropy-injection-driver | tags: linux kernel code | updated: Tue, 16 May 2006 09:56:40 ]
I was installing openswan on my sbc router box. The sbc doesn't have much hardware on it, and what it does have did not contribute to the entropy pool.
I have a few boxes around with relatively good entropy (keyboard/mouse input), but there was no way to pass that entropy to the router for RSA key generation. I had to write some code to fix it. Be warned, it's pretty EVIL...
UPDATE: see below about rng-tools.