OSDev.org

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 : Is there something like a sizeof(example) that will give me the memory space needed by the function example.

Thanks

It is possible that your Example would be auto inlined and not be an function anymore in compiled form.

1) The compiler doesn't know the exact size of the function until after it has been compiled and assembled, i.e. it would require a two-pass compiler to have the function size anywhere in the source.

2) The function doesn't end up as a single block in the executable. Your code resides in the .text section, your "i = 0" reserved space in the .bss section (which doesn't even exist anywhere until after the executable is loaded for execution), and if you had a "i = 42" in there the 42 would be in the .data section. Oh, and if you added a string, it would be in the .rodata section. Now, which size would you want? (And do you want it well done or medium?)

No, there is no way to tell.

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

Erm...

WHAT?

Erm...

Why do you want to copy a function around in memory?

Usually a function is executed by storing its parameters on the stack and then jumping to that address, but in any case that's nothing you do in C code...

I smell massive confusion here. There is no context I could imagine where copying function code makes any sense.

This is because of a special functionnality i want to implement in my OS. Here is a better explanation of what i want to do :

Let's say i have several function stored somewhere in memory from address @a. then i have a table FCT[] with offsets. So far : funct1 -> 1000; funct2 -> 2000; funct3 -> 3000.

So at the moment i do somehitng like RunFunction(@a + FCT[funct1]), and it will run the function funct1 doing (for example) : I know this can be different to what we usually see. Now i'm having a problem with the lenght of function. I would like to have in my table FCT a lenght specific suited to each function.

I hope this makes sense. If you have any idea it'd be much appriciated ^^

Thanks

Solar wrote:2) The function doesn't end up as a single block in the executable. Your code resides in the .text section, your "i = 0" reserved space in the .bss section (which doesn't even exist anywhere until after the executable is loaded for execution), and if you had a "i = 42" in there the 42 would be in the .data section. Oh, and if you added a string, it would be in the .rodata section. Now, which size would you want? (And do you want it well done or medium?)

Nothing is in the bss or data section for local integer variables.

try again when you specify a local array of integers. Also, weren't hashtabled switch() statements outside the function's boundaries?

OK, OK, I screwed up a little. Can we get back to the OP and his function-copy thingy here?

stanko51:

I still don't get why you have to copy the function prior to executing it? That's an enormous performance hit, and I cannot figure out why you don't just jump into the function?

I plan on doing function-copying one day - to upload microcode bits to kernel land so to eliminate bits of IPC overhead for some IRQs

As for getting the length - disassemble and trace all jump instructions to see what parts of code can be reached without call/ret statements. This breaks on the mentioned switch statements since that needs a full data flow analysis.

Alternatively, if you have a list of functions you can guess the length by getting the start of the next function. (needs some linker script trickery to work for the last function.)

There is a background thread that handdle my bunch of functions stored at address @a (e.g. add one, delete one ...etc) and also manipulate my table FCT. Now if another thread calls a function in this table and, in the middle of it, is preempted by the background thread, i figured this could be a problem so i prefered to copy it...

How about applying RCU to the function table, since this looks more like a regular synchronization problem.

On the first thought RCU would deny access to the background thread because the function is being read, which i never want to happen. This background thread should never be denied to execute orders.... But i agree there must be a better way than just copying. I will give it a thought for my next version.

But actually this wouldn't solve my problem. Because anyway i would need to know what is the size of each function to jump to it (or add it) from @a, wouldn't i...

So I guess if the size of a function can't be evaluated , I just have to find an other way and redo the all functionnality >< I was really hoping for a magic way to find how long a function in memory is..

I still don't get it. All you need is a table with function pointers. Someone wants to jump into the function, fine. (Just make sure that the lookup / jump is atomic, i.e. the background thread doesn't change / remove the function pointer between lookup and jump.) Once a client jumped into the function, the background thread could change the table any way it wants...

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.