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@xxxxxxx> 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 >
