Dynamic-loaded libraries, etc.

[Pype.Clicker]

Hello, ...
there's something that troubles me a bit about shared dynamically-loaded libraries ... Every process might have a different memory map, so how will the kernel ensure that - say - gui.dll (or libgui.so) will be mapped at the same virtual address in every process ?
If not mapped at the same address, the library will have to be relocated to its new location, no ? thus, breaking the 'sharability' (as every process will need a separate copy of the library with its own relocation entries written ...)

Now, there is the option of Position Independent Code: have a global register that keeps the address of a jump-table for the functions, so that when the library needs the address of function F (or the address for static variable X), it knows it is located at [ebx + <offset for x>] or [ebx + offset for F in the jump-table]

But locking one register to this still frustrate me ...
Why doesn't IA-32 have a [eip + offset] addressing mode

What do you suggest ?

[Berserk]

Hey,

Does your OS support Dynamically Linked Library's??

I don't know what the hell Dynamically Linked Librarys are, are they the same as Dynamically Linked Librarys??

Ciao ;D

[Berserk]

I meant that i don't know what the hell Dynamically Loaded Librarys are.

Sorry, did a typo ::)

Ciao

[Schol-R-LEA]

I meant that i don't know what the hell Dynamically Loaded Librarys are.

Sorry, did a typo ::)

Well, there's a reson to become a member, you see? You could have edited the original and none would be the wiser.

Yes, dynamically loaded libraries are the same as dynamically linked libraries. I imagine that it was a typo on Pype.Clicker's part, though it comes to mean more or less the same thing - a library that is loaded on demand, whenever a program using code within it is called, and which can be shared as a single library image by multiple programs.

[Schol-R-LEA]

Hello, ...
there's something that troubles me a bit about shared dynamically-loaded libraries ...

I'd recommend reading through Linkers and Loaders by Levine as a place to start; see the book thread for details. the 4th edition of Operating Systems by Stalllings also covers it briefly in the section on memory management. I'm not sure what other books talk about it; linking and loading seem to get short shrift in most OS books.

Every process might have a different memory map, so how will the kernel ensure that - say - gui.dll (or libgui.so) will be mapped at the same virtual address in every process ?

As I understand it, there are some systems that do this, yes. The libraries are mapped to specific areas in the kernel memory, and there is a master redirection table indicating where the specific functions and shared data are. This approach is considered too inflexible, however. This approach is called 'statically shared libraries' (as opposed to non-shared libraries on the one hand, and dynamically shared libraries on the other).

If not mapped at the same address, the library will have to be relocated to its new location, no ? thus, breaking the 'sharability' (as every process will need a separate copy of the library with its own relocation entries written ...)

Actually, if I understand correctly, in the case of dynamic loading and linking the redirection goes in the other direction. the library sets up it's table of handlers on loading, and hands it to the OS; when a program is loaded, the loader checks the OS library relocation tables and uses the thunks the addresses into the program. At least that seems to be how it works, for what I am reading here now at 2 am with a case of terminal bleary-eye. Perhaps it will make more sens when I re-read it later...

Now, there is the option of Position Independent Code: have a global register that keeps the address of a jump-table for the functions, so that when the library needs the address of function F (or the address for static variable X), it knows it is located at [ebx + <offset for x>] or [ebx + offset for F in the jump-table]

PIC is pretty much a necessary part of dynamic sharing, IIUC.

But locking one register to this still frustrate me ...
Why doesn't IA-32 have a [eip + offset] addressing mode

Oh, but it does! It's called the 'segmented memory model'

[Tim]

If not mapped at the same address, the library will have to be relocated to its new location, no ? thus, breaking the 'sharability' (as every process will need a separate copy of the library with its own relocation entries written ...)

Indeed it does. Windows, which has always targetted the x86 (with its small number of general-purpose registers) relocates DLLs that can't be loaded at their default address. All of the system DLLs have their base addresses carefully chosen so that under normal circumstances they don't clash. In practice, relocation occurs rarely (you've got a 2GB user address space to play with), but if it does, loading takes quite a bit longer.

UNIXes tend to deal with this by using Position-Independent Code, which performs better of CPUs that have more GPRs than the x86. Segmentation would be a good way to implement proper PIC on the x86 but, for reasons that have been covered before, hardly anyone uses it.

[Pype.Clicker]

Hmmm ... segmentation has been known to be time-consuming and difficult to use with C ... however, i guess the loader could be generating a small jump table that would use FAR jumps instead of regular ones ...
this adds a bit overhead, but at least, the function can be called from both inside and outside of the library ... except the external components would go through the jump table ...

now, the difficulty is for functions that return addresses ! some kind of supervisor should translate the function address into a jumptable address runtime ... or maybe it could be done by the 'jumper' stuff ...

seems like it is feasible .. but complicated :-/

[Tim]

Very complicated. Using far pointers would make passing pointers to and from a DLL difficult. For example:

Code: Select all

--- dll.c
print_params p = { green_background | white_foreground, { 0, 0 } };

void ADllFunction(const char *str, void (*callback)(char, print_params*))
{
    while (*str != '\0')
    {
        callback(*str, &p);
        str++;
        p.x++;
    }
}

---- app.c
void print_function(char ch, print_params *p)
{
    // write to screen
}

int main(void)
{
    char str[] = "Hello, world!";
    ADllFunction(str, print_function);
}

There are three problems that I can see in this code:

• Calling a function in an EXE directly from a DLL won't work, because CS is different for each
• Passing data on the stack to a DLL won't work, because the compiler assumes DS == SS (which it won't be)
• Passing pointers from the DLL to the EXE (and vice versa) won't work, because a flat address space is assumed

You could fix these either by translating all pointers backwards and forwards, or modifying the compiler and linker heavily, but either solution would be far less efficient than the problem you're trying to solve (relocating DLLs).

PS: the fourth problem is that I don't return anything from main()