Hello,

while trying to find out the reasons of a strange behaviour of my library, I stumbled upon this:

cpp file 1 of library:

void printRelativeFunctionAddresses()
{
    printf("printRelativeFunctionAddresses-giveMeAOne: %i\n",int(printRelativeFunctionAddresses)-int(giveMeAOne));
    printf("printRelativeFunctionAddresses-giveMeATwo: %i\n",int(printRelativeFunctionAddresses)-int(giveMeATwo));
}

Cpp file 2 of library:

extern "C" __attribute__((visibility("default"))) int giveMeAOne()
{
    return(1);
}
extern "C" __attribute__((visibility("default"))) int giveMeATwo()
{
    return(2);
}

the function printRelativeFunctionAddresses prints the same value everytime I start the library from a specific client application A. But when I use a different client application B (but that loads the exact same library), then the output is different! How can that be? Are functions shifted around during the library load operation?

I am running the library on Ubuntu 32bit, using Qt5.1.0

Thank you swiftcoder.

Yes, I understand that the functions should all get a same offset, but is it possible that one function gets a different offset that the others?

Let's say, that I have 2 functions in my library: A() and B().

My client application loads the library and binds the functions. I print location of function B RELATIVE to the location of functions A:

A-B=position of function B relative to function A=X

My question is: will X always be the same for the same library binary? Could it be that the library loaded decided one time to put function B before function A? (and vice-versa)

Thanks Khatharr,

I had a look at the link which is very exhaustive, but probably too much Windows oriented.

I am using g++ V4.6.3 under Ubuntu. It is invoked under the whoods by Qt (Qt V5.1.0).

You are telling me that functions can get shifted around when loaded into memory, and the loader/binder takes care of correcting for that. But it seems that in my case, the loader fails at doing its job correctly:

I have library-internal calls to functions A and B too. And those calls will sometimes call the wrong address (as strangely as it seems!). My library and client application run on Windows, Mac and Linux. Windows and Mac run fine. Linux used to run fine until I switched to the newest Qt version (but still same compiler). Is it possible that Qt appended additional compilation flags that influence the way my library gets loaded?

I'm only familiar with how this works in Windows PE (exe and dll) files:

- The assembler and linker will organize machine code however it feels like it. Typically a compiler will generate each function as they appear in the source file and the linker will generate a library in the order that objects are passed to it - this is mainly subject to change due to optimizations.

- The output object/library/executable files are partitioned into 'sections'. Each section can be relocated anywhere in RAM when the loader loads it.

- Once the exe or dll is generated, the code within each section of that file will assume that the section will be treated as an immutable chunk. Function calls within one section rely on this.

- A relocation table can be used to remap pointers within the code sections (typically addresses to other sections within the same file), but this never changes the relative offsets of things within the same section.

You should expect code within one section to get the same relative offsets to each other, but only until you recompile or re-link your exe/dll. It will not change between runs of the program. You should never rely on cross-section offsets being the same, OR absolute addresses being the same between runs of the same app, even if you did not recompile.

I've never inspected Linux binaries closely to see if they use this same pattern or not.