OSDev.org

Posted: **Fri Apr 17, 2009 7:44 am**

stanko51 wrote:delete the function pointer

You serious?

On the first thought RCU would deny access to the background thread because the function is being read, which i never want to happen

It doesn't - read again.

Come on, its not that hard.

Posted: **Fri Apr 17, 2009 7:52 am**

stanko51 wrote:but it couldn't delete/modify the function in memory on which the pointers would point to.
So if you just delete the function pointer you have an memory leak with the funtion still in memory and nothing pointing on it anymore.

btw, The table of function pointers already exist, it's the FCT table i talked about earlier.

If the number of functions in this FCT is small, you could link each function into a separate section in your object/executable file (or have it loaded into a separate section in virtual memory), and you could use the length of the section instead. This could solve problems with switch() statements which need additional data to work correctly (just link any additional constants into the same section).

Edit: this problem smells like you are trying to do either 1) hotpatching or 2) some kind of just-in-time compilation. Am I correct?

Posted: **Fri Apr 17, 2009 8:27 am**

stanko51 wrote:but it couldn't delete/modify the function in memory on which the pointers would point to.
So if you just delete the function pointer you have an memory leak with the funtion still in memory and nothing pointing on it anymore.

You still didn't say what you're up to. Is this user-space we're talking about? Kernel space? What is happening?

(This, by the way, is IMHO an excellent example what code comments are good for; stanko51 has explained what is happening - equivalent to the source - but we're all guessing why it is happening - equivalent to the comment...)

You are obviously trying to handle code as just another data object, on the individual function level. That is highly unusual, and I got this nagging suspicion that, in the end, it's not even what you want to do...

Posted: **Fri Apr 17, 2009 8:32 am**

stanko51 wrote:Thank you for your answers.

but then i don't get how are the instructions stored in memory ? Is it not from an adress and then read the following memory?

If for example i have a RunFunction(&example); it will get the function from address &example copy it and execute it.
My problem is basically when i do memcpy(&example, dest, lenght); how can i know what is the value of lenght?

For a small function i just assume the lenght < 1000. So i do memcpy(&example, dest, 1000); and RunFunction work fine. It just copies 1000 bytes from the address &example. But Just setting a random big value is not really good programming method. Does anyone have an idea on how i could estimate this value ?

Thanks

There are more problems:

3) The instructions of the function is not required to be consecutive in memory.
4) It may be that memcpy from a function pointer may not be permitted.
5) Even if it succeeds it's possible that the memory copied to does not permit execution.
6) Even if it does the code may be position dependent.

Posted: **Fri Apr 17, 2009 8:48 am**

skyking wrote: 5) Even if it succeeds it's possible that the memory copied to does not permit execution.
6) Even if it does the code may be position dependent.

Yep; 6) has been jumping up and down in the back in my head trying to get attention, but somehow I looked the other way. 5) is the "NX flag" thingy most OS designers get so excited about because it's a great way to make life difficult for malware...

Posted: **Fri Apr 17, 2009 10:10 am**

stanko51 wrote:Hello all,

This is just a question about general fonctionnality of C language.

How can i know the size that the code of a function use in memory.

For example :
Code: Select all
int example (void){
  int i = 0;
  print(i);
  return 1;
}
Is there something like a sizeof(example) that will give me the memory space needed by the function example.

Thanks

It seems everything has gotten a little offtopic.. but I do not see why you can not just use a function table for this kind of thing. The only easy way to get the size of a function is to use pure assembly.. but if you really must get it from C then there is this hackish idea I have..

Code: Select all

int example(void){
  int i=0;
  printf(i);
  return 1;
  __asm volatile("_example_end:\n"); //depending on compiler, you may not want the leading _
}

int example_size=example_end-example+MAGIC_NUMBER;

The MAGIC_NUMBER is different among compilers and greatly depends on optimization levels, how many stack variables you have, etc etc.. It is really almost impossible to determine without testing each and every function to see when they actually "ret" and it can very easily change by the slightest change to even the layout of your code.

That being said, I highly do not recommend it.

Also, on a side-note, if you get the address of a function, it is guaranteed to be compiled in memory(not inline'd).

Posted: **Fri Apr 17, 2009 11:09 am**

stanko51 wrote:but it couldn't delete/modify the function in memory on which the pointers would point to.
So if you just delete the function pointer you have an memory leak with the funtion still in memory and nothing pointing on it anymore.

btw, The table of function pointers already exist, it's the FCT table i talked about earlier.

Sorry to burst your bubble, you can't DELETE a function pointer, because when using the 'delete' keyword on a pointer, it will free the memory allocated by the variable it points to. With function pointers, you can't delete the functions stored in them, you CAN redirect the function pointer to another function however, but this can easily be stopped with:

Code: Select all

void foo() {}
void bar() {}

//...

//Normal function pointer:
void (*p1) () = &foo;
p1 = &bar; //Will compile successfully.

//Function pointer that can't be modified:
void (*const p2) () = &foo;
p2 = &bar; //Will fail to compile, because the pointer can't be modified.

If you're talking about assigning a value to a function pointer which will be locked 'AFTER' the 'initialization value', that's impossible. You can however make a private table of adjustable function pointers and make a load of accessors that return a pointer to the same location (just an example, as it's a pretty large overhead), that way the original pointer will never be modified (unless you modify it yourself).

Posted: **Fri Apr 17, 2009 11:38 am**

Hi,
I can't think of any valid way to do what stanko51 said that works in all compilers and platforms . (ie getting the length of function ) . There is no 'in-bult' C support .

Regards
Shrek

Posted: **Sun Apr 19, 2009 12:19 am**

In order to find the offset & length of a function as well as copy it in a way that will actually work you may need to write your own linker (or extend an existing one) and create your own executable format. When you load your executable you can have a table for each function that describes beginning offset, length & how to relocate position dependent code. In the code you could just do something like: "extern FunctionTable *fct;" and the linker would auto-generate the table.

Posted: **Sun Apr 19, 2009 1:14 am**

Well, my OS does copy a piece of code to a different location before executing it. It copies the startup code for secondary CPUs below the 1MB mark, since they will start in real mode and GRUB loads my kernel code above 1MB.

In ASM, the length of the code can be determined quite easily: You can just add labels at the beginning and the end of the function. For C code, you could try something similar using inline ASM, but remember that your compiler will add some additional code at the beginning and the end of your function, for example, to set up a stack frame. But this is just a rough idea, I have not tested it...

Posted: **Sun Apr 19, 2009 7:54 am**

Ooh, I have a question:

Are the signatures for all of the functions you want to copy around the same?
I.e. void func1(int param), void func2(int param), etc.

If they are, then it would be much faster and much easier to use an array of regular function pointers:

Code: Select all

typedef void (funcPtr*)(int param);

funcPtr array[] = {func1, func2, func3}

for(int i = 0; i < numFuncs; i++)
  array[i](param);

// change 3rd function:
array[2] = funcX;

// do more stuff without slow copying and hacky size finding methods...

You don't need to free() them because it's like using a pointer to a global variable.

You might want to look up the proper syntax for declaring the function pointer type, though. It's been a while since I last did anything like that...

Posted: **Sun Apr 19, 2009 9:51 pm**

Code: Select all

typedef void (*func)(int param);
...

func foo;
void bar(int p){
}
...
foo=bar;

Posted: **Tue Apr 21, 2009 8:37 am**

earlz wrote:

Code: Select all

typedef void (*func)(int param);
...

func foo;
void bar(int p){
}
...
foo=bar;

Don't you mean

Code: Select all

foo = &bar;

or am I missing something?

Posted: **Tue Apr 21, 2009 9:15 am**

Casting functions to function pointers is similar to casting an array to a pointer. The only difference is that your statement should also work, whereas with an array you'd need &arr[0] instead of just &arr.

P.S. not entirely sure terminology is correct, but it should get the idea across...

Posted: **Tue Apr 21, 2009 9:11 pm**

Creature wrote:
earlz wrote:
Code: Select all
typedef void (*func)(int param);
...

func foo;
void bar(int p){
}
...
foo=bar;
Don't you mean
Code: Select all
foo = &bar;
or am I missing something?

func==&func... I mean, how would a compiler handle dereferencing a function pointer?

OSDev.org

function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C

Re: function lenght in C