sizeof(function) functionality

[Kristis Makris]

Hello, thanks for the reply.

On Mon, 2003-07-07 at 09:01, Ben Davis wrote:
> On Monday 7 July 2003 4:55 pm, Alexandre Oliva wrote:
> > On Jul  6, 2003, Kristis Makris <kristis.makris@asu.edu> wrote:
> > > Other than instantiating a volatile variable right after a function and
> > > evaluating variable - &funcname, is there another way of retrieving the
> > > size a function occupies in memory using gcc ?
> >
> > First, this won't get what you want, because variable will likely be
> > placed in a different section.  I can't think of any clean way to do
> > this in C, especially if you consider functions-as-sections as a
> > possibility.

Agreed.

> Allegro <http://alleg.sf.net/> has used the following technique for a long 
> time:
> 
> #define END_OF_FUNCTION(name) void name##_end(void) { }
> #define END_OF_STATIC_FUNCTION(name) static void name##_end(void) { }
> 
> void func1(void) { ... } END_OF_FUNCTION(func1);
> void func2(void) { ... } END_OF_FUNCTION(func2);

Interesting how you propose that. I actually came up with this last
night:

#define sizeof_function(x) ( (unsigned long) (&(endof_##x)) - (unsigned
long) (&x)) 
#define endof_function(x) void volatile endof_##x() {}
#define DECLARE_END_OF_FUNCTION(x) void endof_##x();

Note the volatile keywoard, also used when functions are declared. It
has the effenct of the function and its end  sticking next to each
other, or at least out of what I noticed:

void volatile test()
{
 ...
}
endof_function(test);

DECLARE_END_OF_FUNCTION goes in header files, but still is a maintenance
problem.

What I really want to do is have only one macro that expands into the
above; add the volatile keyword and append the endof_function at the
end. I'd like to add endof_function labels for a large collection of
sources, and it feels like the compiler should be able to add those for
me.


> Then there are more macros for locking the functions in memory, and these 
> macros merely find the difference between pointers to the two functions. The 
> purpose of this is to prevent any disk access from occurring when the 
> functions are called.

While I was reading this sentence I assumed you meant the mlock() system
call. I am afraid I don't understand how disk access came into the
equation here.

> Note that this is only done on DJGPP; other operating systems supported by 
> Allegro (like Windows and Linux) use threads and have re-entrant disk access 
> functions, so the locking is unnecessary and the macros expand to nothing. So 
> I have no idea how portable this technique would be. It could conceivably be 
> broken by a compiler that set func2's entry point to be the 'return' 
> instruction of func1, for instance ...

I can see sizeof_function being rewritten to -sizeof_function, or the
absolute value, in architectures where the stack grows the other
direction, for the portability issue.

> Assuming it doesn't exist already, I think sizeof(function) or something like 
> it would be a very useful GNU Extension for future GCC versions :)
> 
> Ben
>