Linux with MMU on NEEK

Hi,

--- Quote Start ---

Why is all this done with relocatable code with direct calls and not with position independent code using indirect or relative calls ?

--- Quote End ---

In fact, the compiler will decide the use of direct calls 'call' and relative calls 'callr'. The linker only changes those addresses and can't change those instruction sequence. This means that once the compiler produces a code 'call ****', we don't have any method to change this code to a relative call. When we compile the next program without option switch like '-shared' or '-fPIC',

void func(void)
{
    printf("hello Nios\n");
}

the printf is called by a direct call. At its linking time, the linker finds that the 'printf' is included in a shared library, so the linker adds a GOT(global offset table) and the address resolving algorithm, and relocates the target adddress of direct call to the entrance of resolving algorithm. In this 'libnano-X.a' case, programs were compiled without '-shared', but it is linked to a shared library after. The value 0x870 is the entrance address of resolving algorithm, but the shared library is loaded to different addresses, so we need one more relocation at the loading time, but the relocation information has been already expired....

--- Quote Start ---

(In fact I need to look up what the mnemonic "call 0x2000870" in fact means, as the code dword can't specify a 32 Bit address, so maybe this in fact is the same as "call 0x870" as you maybe suggested.

--- Quote End ---

Yes, 'call 0x2000870' is only a mischief of the debugger. The real memory contents are '0008ac40', i.e. 'call 0x870'.

Kazu