Hi,
The "single return" paradigm of drivers/char/vt.c:tioclinux() surprised
me at first glance. But I'm now trying to maintain a patch which adds
probes at entry and exit of functions for performance instrumenting, and
this paradigm is a great help, and on the other hand, maintaining the
patch for drivers/scsi/sg/sg_ioctl() is really a drudgery whenever a
little thing changes or a case is added... I don't know what people from
the linux trace toolkit think of this?
Gcc compiles every function into "one return form" anyway, so there's no
penalty in defining a retval variable, having it assigned, and doing a
break or goto out. I has been said to be of religious concern, but
having this habit keeps tracing patches simple. And if one needs, say, a
spinlock at entry & exit, the work is almost done. One could still have
a second exit for error cases, but no more.
Could this be added to CodingStyle or something?
Regards,
Samuel Thibault
On Sad, 2003-07-26 at 23:16, Samuel Thibault wrote:
> Hi,
>
> The "single return" paradigm of drivers/char/vt.c:tioclinux() surprised
> me at first glance. But I'm now trying to maintain a patch which adds
> probes at entry and exit of functions for performance instrumenting
gcc will already dop that for you - and the tools already exist to
extract the data I believe (at least Ingo used to have some). When you
tell gcc to build with profiling it provides the right hooks for you to
provide alternate code to the libc profile code
x
Le dim 27 jui 2003 11:43:22 GMT, Alan Cox a tapot? sur son clavier :
> On Sad, 2003-07-26 at 23:16, Samuel Thibault wrote:
> > The "single return" paradigm of drivers/char/vt.c:tioclinux() surprised
> > me at first glance. But I'm now trying to maintain a patch which adds
> > probes at entry and exit of functions for performance instrumenting
>
> gcc will already dop that for you
Indeed. The thing is that this automatic call only gives you the
function address and its caller site (yes, it couldn't give much more),
so you have to lookup symbols in the System.map, you can't do this with
modules (at least for non-exported functions which don't appear in
/proc/ksyms), and you can't get the return code.
I'll yet add this possibility for quickly adding tracing to a particular
file by just adding CFLAGS_file.o=-finstrument-functions to the Makefile,
before progressively replacing it by hand-written probes with the wanted
parameters. The single-exit issue still remains then.
Thanks anyway,
Regards,
Samuel
On Sun, Jul 27, 2003 at 11:43:22AM +0100, Alan Cox wrote:
> When you tell gcc to build with profiling it provides the right hooks
> for you to provide alternate code to the libc profile code
Starting with gcc 3.3, there is __attribute__((cleanup(foo))),
which, when applied to a local variable, is effectively
destructors for C. Foo will be invoked with a pointer to the
variable just before the variable goes out of scope.
r~