[SOLVED] Shared objects - mapping and linking

[gerard4143]

Hi,

I have a question about shared objects and when mapping and linking is established in the following code...Well more of a verification.

getsetx.c - shared object source code

unsigned long x = 0;

unsigned long getx(void)
{
	return x;
}

void setx(unsigned long val)
{
	x = val;
}

getsetx.c compile lines

gcc -fPIC -c getsetx.c
ld -shared -o getsetx.so getsetx.o

testit.c - Main executable source

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

extern unsigned long getx(void);
extern void setx(unsigned long);

int main(int argc, char**argv)
{
	int choice = 0;
	unsigned long val = 0;

	while (true)
	{
		fputs("(0)exit (1)view (2)set->", stdout);
		fscanf(stdin, "%d", &choice);

		if (choice < 1) break;

		if (choice == 1) fprintf(stdout, "ans->%lu\n", getx());

		if (choice == 2)
		{
			fputs("enter a value->", stdout);
			fscanf(stdin, "%lu", &val);
			setx(val);
		}
	}

	exit(EXIT_SUCCESS);
}

testit.c compile line

gcc testit.c ./getsetx.so -Wall -ansi -pedantic -o testit

Now its my understanding when I execute ./testit, getsetx.so will get mapped into its address space at start up and testit will link any functions as they are needed...So is this correct, because this is what I'm experiencing...Thank-you, Gerard4143

[darkrose0510]

Umm, your compile lines look a bit out to me, and will result in the .so being build into the executable, rather than linked against as a share object...

gcc -fPIC -c getsetx.c
ld -shared -o libgetsetx.so getsetx.o -Wl,-soname,libgetsetx.so

gcc testit.c -L/path/to/shared/object/parent/directory -lgetsetx -Wall -ansi -pedantic -o testit

Would result in it behaving correctly I think.

[JohnGraham]

Umm, your compile lines look a bit out to me, and will result in the .so being build into the executable, rather than linked against as a share object...

I'm quite sure you can reference shared objects directly - using ./blah.so will cause the dynamic linker to look for blah.so in the current directory, which is one way you can bypass its normal search paths. You can compile the sample programs and run ldd on the resulting executable to check.

Now its my understanding when I execute ./testit, getsetx.so will get mapped into its address space at start up and testit will link any functions as they are needed...So is this correct, because this is what I'm experiencing...

That's basically it - although for small shared libraries, the dynamic linker seems to load functions into memory at program load-time, as opposed to when they're needed (for example, you could probably delete or move getsetx.so after you start testit, and everything would be fine.

You can set LD_DEBUG=all in the environment to get the dynamic linker to print out what it's doing (or LD_DEBUG=help for debug options).

[gerard4143]

That's basically it - although for small shared libraries, the dynamic linker seems to load functions into memory at program load-time, as opposed to when they're needed (for example, you could probably delete or move getsetx.so after you start testit, and everything would be fine.

Thank-you for the replies...One comment. If the executable(testit) maps the shared object(getsetx.so) into its address space at start up, why would it matter if the shared object is moved or deleted after start-up.....testit has a copy(MAP_PRIVATE) at start up so any changes or deletions should go unnoticed.

[JohnGraham]

If the executable(testit) maps the shared object(getsetx.so) into its address space at start up, why would it matter if the shared object is moved or deleted after start-up.....testit has a copy(MAP_PRIVATE) at start up so any changes or deletions should go unnoticed.

I thought that large object files (not sure how large) may be loaded on demand in order to save memory - however, looking into it a bit more, I can't find anything on t'web to really back that up, so I don't know where I got that from. Sometimes things like that just get into my head for no reason.

Either way, symbols are only resolved on demand (though you can change this by setting LD_BIND_NOW in the environment) even if the associated data is already in memory.

[gerard4143]

I thought that large object files (not sure how large) may be loaded on demand in order to save memory - however, looking into it a bit more, I can't find anything on t'web to really back that up, so I don't know where I got that from. Sometimes things like that just get into my head for no reason.

Either way, symbols are only resolved on demand (though you can change this by setting LD_BIND_NOW in the environment) even if the associated data is already in memory.

Thanks JohnGraham