[RFC] single return paradigm

[RFC] single return paradigm

[Samuel Thibault]

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

Re: [RFC] single return paradigm

[Alan Cox]

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

Re: [RFC] single return paradigm

[Samuel Thibault]

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

Re: [RFC] single return paradigm

[Richard Henderson]

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~