CODEWITHSUNDEEP
cfunctionlinker
phantom
phantom

Reputation: 3342

How are function calls resolved?

When a function is called, execution is shifted to a point indicated by the function pointer. At the start of execution, the executable code has to be loaded from disk.

How is the correct function pointer called? The executable code is not mapped into virtual memory at the same location every time, right? So how does the runtime make sure that a call to a function always calls the correct function even if the location of the executable code is different for each execution?

Consider the following code:

void func(void); //Func defined in another dynamic library

int main()
{
    func();
    //How is the pointer to func known if the file containing func is loaded from disk at run time?
};

Upvotes: 1

Views: 1136

Answers (3)

Kaslai
Kaslai

Reputation: 2505

The way that function pointers are resolved is really quite simple. When the compiler chain spits out an executable binary, all internal addresses are relative to a "base address." In some executable formats, this base address is specified, in others it is implied.

Basically, the compiler says that it assumes execution will start at address A. The runtime decides that it should actually start at B. The runtime then subtracts A and adds B to all non-relative addresses in the binary before executing it.

This process also applies to things like DLLs. Dynamic libraries store a list of addresses relative to the base pointer that point to each exported function. Names are often also associated with the list, so that you can reference a function by name. When the library is loaded, the address translation is applied to everything, including the address table. At that point, a caller just has to look up the address in the table that was translated, and then they'll have the absolute address of a given function.

In older operating systems, long long ago (and, in some cases, even today), well before things like address space layout randomization, memory pages, and multitasking operating systems, programs would just be copied to the specified base address in memory where it would then be executed.

In modern operating systems, one of a few things can happen, depending on the capabilities or requirements of the platform and application. Most operating systems handle native binaries as I described in the second paragraph, however some applications (such as running 16-bit x86 on later architectures) can involve more complex strategies. One such strategy involves giving the code a static virtual address space. This has various limitations, such as the need for an emulation/compatibility layer if you want it to interact with external code (like a windowed console or the network stack).

As the need for 16-bit support declines though, that sort of scheme is used less and less. Giving all programs their own unique address space (rather than letting it overlap) promotes the use of shared libraries, services, and other shared goodies.

Upvotes: 3

ZbyszekKr
ZbyszekKr

Reputation: 512

You can print the 'func' and see whether is has the same address during every execution like this:

printf("%u", function);

For me it's the same address every time (virtual memory wise).

Upvotes: -1

Vitaly Greck
Vitaly Greck

Reputation: 668

In general, function calls are resolved statically. When you compile the file, first - .o (or .obj) file is created. All known addresses - are local functions (from this file). Unknown are "extern" functions. Then, linking is performed. Linking completes address mapping for every function which is "extern". If any names are missing - linking error occurs.

How is the correct function pointer called? Function pointer is function address, function name is function address. Both are values, not L-values. &func and func are absolutely same.

Loading or PE (or ELF) files is a process or loading the executable to memory. Too much information to explain. Basically, just for clarification, consider: every function has its own address in the process address space.

Upvotes: 0

Related Questions