A little bit of dynamic linking on i386

[giszo]

Hey.

I just implemented 99% of my dynamic linking code but I run into a little problem with the R_386_COPY reloc type. So I am here to get some advice on my problem.

As I understood from the ELF docs, to resolv a R_386_COPY type reloc I have to copy the memory contents from the existing symbol to the place pointed by the reloc info. Lets say I have an int variable in a dynamic library and this variable is referenced from the main application. In this case a R_386_COPY type reloc will be added to the main application image, so the contents of the variable will be copied to the application during the relocation process of the whole image. My problem is that who will/should take care of that situation when the variable in the dynamic library has been changed? How will the main application get the updated value?

Thanks,
giszo

[xenos]

According to Sun's "Linker and Libraries Guide", which contains a section on copy relocations, the main application cannot monitor changes of copy-relocated variables within the shared library, so copy relocations are pretty useless for dynamical data. (Plus, there is an overhead for copying data at link time.) For dynamical data, function interfaces should be used instead, which return either directly the dynamical data, or a pointer to dynamical data.

[giszo]

Yes, this is almost the same what I came up with.

The problem is that for example the ncurses library has the COLS definition as an "extern int" stuff instead of a function returning it, etc. This makes it impossible for me to use ncurses as a shared library as this int variable will be initialized during runtime, so when I copy it at link time, I will simply copy a zero value. But, the ncurses library works on Linux somehow with dynamic linking...

So the question is that how is it possible to work on Linux? What I am doing wrong?

[xenos]

I guess I was a bit confused yesterday by the stuff I found in this linker guide. Here is the relevant part:

http://docs.sun.com/app/docs/doc/817-19 ... 604?a=view

The dynamic linker copies the contents of the referenced external variables into some place within the executable, which has been reserved when the executable was built by the static linker. This means that the size of the copied data is fixed.

At load time, the dynamic linker copies the initial data from the shared library into the reserved place within the executable. This copy is now used not only by the executable, but also by shared libraries within the same process image. (At least this is what I get from the link quoted above - although I am confused, because it means that this data is not shared between different process images, and it it needs to be updated, this must be done separately for each process image.) The original data within the shared library is not used anymore after this step.

The drawback (which I was confused about yesterday) is not that the copied data is never updated again, as I wrote in my last post. Instead, the problem already occurs when the executable is built: The static linker reserves space for the shared data, so the size of this data must be known. If the original library is replaced by a new, updated one, this size may have changed. The link above shows an example where the copied data is an array of pointers. The space for this array needs to be reserved within the executable, but if a new version of the library comes out and the size of this array has changed, the executable needs to be re-built.

So, to get back to your question: You need to make sure that 1. the initial data is copied from the shared library at load time, 2. shared libraries within the same process image use this copy at run time.

[giszo]

I think I got how it should work. Thanks for all the help, now I am going to change my implementation and let's see how it will work.