Linux with MMU on NEEK

Hi,

--- Quote Start ---

Sorry, but I don't understand the details, and in fact I'm not really sure what difference this update makes.

--- Quote End ---

By this new (static) linker, you can make shared libraries from pre-compiled position dependent codes, and the new dynamic linker can relocate those adequately.

For example, if you compile a sample program like

/** a.c --- Test for Nios Dynamic Linker  **/
extern func_b(int);
extern int j;
int func_a(int i)
{
    j = func_b(i);
    return j;
}

,with the command

nios2-wrs-linux-gnu-gcc -c -G0 -g a.c -o a.o

the compiler will generate relocating information with its position dependent codes as follows.

Relocation section '.rela.text' at offset 0x7b0 contains 5 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000018  00000e04 R_NIOS2_CALL26    00000000   func_b + 0
00000020  00000f0b R_NIOS2_HIADJ16   00000000   j + 0
00000024  00000f0a R_NIOS2_LO16      00000000   j + 0
0000002c  00000f0b R_NIOS2_HIADJ16   00000000   j + 0
00000030  00000f0a R_NIOS2_LO16      00000000   j + 0

But the old (static) linker can not pass these information to the shared library headers.

Added codes of the new linker will do it.

Relocation section '.rela.dyn' at offset 0x18c contains 5 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
0000021c  00000404 R_NIOS2_CALL26    00000000   func_b + 0
00000224  0000020b R_NIOS2_HIADJ16   00000000   j + 0
00000228  0000020a R_NIOS2_LO16      00000000   j + 0
00000230  0000020b R_NIOS2_HIADJ16   00000000   j + 0
00000234  0000020a R_NIOS2_LO16      00000000   j + 0
Relocation section '.rela.plt' at offset 0x1c8 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
000012fc  00000426 R_NIOS2_JUMP_SLOT 00000000   func_b + 0

.

The new dynamic linker 'ld.so.1' will do the relocation for these new items, ' R_NIOS2_CALL26', 'R_NIOS2_HIADJ16' and 'R_NIOS2_LO16'.

--- Quote Start ---

Did you fix a problem ?

--- Quote End ---

Yes, but partially fixed.

--- Quote Start ---

In what cases dopes this problem hit ? (Kernel basic code, Kernel Modules (which i learned would not work before), user land programs, user land so's) ?

--- Quote End ---

This modifications are only applied to user-land so's. Newly added codes never work without two switches '-shared' and '-Bsymbolic'.

--- Quote Start ---

Will this get included into the distribution ?

How ?

--- Quote End ---

I don't know, because I'm only a Sunday programmer.

--- Quote Start ---

Is MontaVista and the other commercial provider aware of this ? Why does it not hit them ?

--- Quote End ---

I really don't know who wrote these codes. But I have a little bit doubt whether the implementer do his job seriously or not. The codes are messy, confused and have many un-fixed parts. Sometimes I encounter unbelievable comments like

/* The runtime resolver receives the original function arguments in r4
   through r7, the shared library identifier from GOT? in r14, and the
   relocation index times four in r15. It updates the corresponding PLT GOT
   entry so that the PLT entry will transfer control directly to the target
   in the future, and then transfers control to the target. */

.

Why there exists '?' after GOT[1] ? It seems to me that this implementer doesn't know the structure of GOT well.

Kazu