Linux with MMU on NEEK

Hi,

I'm testing the dynamic linker and shared libraries of Nios system. Once I experienced that the static library 'libnano-X.a' generates SIGSEGV and I believed that this was caused by the wrong relocation of 'ld.so.1'. For example,

00017328 <GrSetErrorHandler>:
   17328:    defffc04     addi    sp,sp,-16
   1732c:    dc400015     stw    r17,0(sp)
   17330:    044000f4     movhi    r17,3
   17334:    8c63be04     addi    r17,r17,-28936
   17338:    dd400215     stw    r21,8(sp)
   1733c:    202b883a     mov    r21,r4
   17340:    8809883a     mov    r4,r17
   17344:    dfc00315     stw    ra,12(sp)
   17348:    dcc00115     stw    r19,4(sp)
   1734c:    0008ac40     call    8ac4 <_init+0x408>     <----- this address must be relocated as loading adr. +  0x8ac4.
   17350:    d4e29517     ldw    r19,-30124(gp)
   17354:    8809883a     mov    r4,r17
   17358:    d5629515     stw    r21,-30124(gp)
   1735c:    00087a00     call    87a0 <_init+0xe4>       <----- this address must be relocated as loading adr. +  0x87a0.
   17360:    9805883a     mov    r2,r19
   17364:    dfc00317     ldw    ra,12(sp)
   17368:    dd400217     ldw    r21,8(sp)
   1736c:    dcc00117     ldw    r19,4(sp)
   17370:    dc400017     ldw    r17,0(sp)
   17374:    dec00404     addi    sp,sp,16
   17378:    f800283a     ret

but the result is as follows.

0x2aae3328:    addi    sp,sp,-16 
0x2aae332c:    stw    r17,0(sp) 
0x2aae3330:    movhi    r17,3 
0x2aae3334:    addi    r17,r17,-28936 
0x2aae3338:    stw    r21,8(sp) 
0x2aae333c:    mov    r21,r4 
0x2aae3340:    mov    r4,r17 
0x2aae3344:    stw    ra,12(sp) 
0x2aae3348:    stw    r19,4(sp) 
0x2aae334c:    call    0x20008ac4          <----- Wrong relocation?
0x2aae3350:    ldw    r19,-30124(gp) 
0x2aae3354:    mov    r4,r17 
0x2aae3358:    stw    r21,-30124(gp) 
0x2aae335c:    call    0x200087a0         <-----  Wrong relocation?
0x2aae3360:    mov    r2,r19 
0x2aae3364:    ldw    ra,12(sp) 
0x2aae3368:    ldw    r21,8(sp) 
0x2aae336c:    ldw    r19,4(sp) 
0x2aae3370:    ldw    r17,0(sp) 
0x2aae3374:    addi    sp,sp,16 
0x2aae3378:    ret

.

But the real fact is that no one relocates these codes. These codes are already relocated by the (static-) linker, and the elf-header has no relocating information when it's loaded to the memory. With the switch '-shared', we can avoid this situation, but if we indicate an option switch '-prefer-non-pic' for shared libraries, the same thing will occur.

Next code is the disassemble result of 'libmpeg2.so'.

00004660 <mpeg2_init>:
    4660:    d0a03017     ldw    r2,-32576(gp)
    4664:    defffb04     addi    sp,sp,-20
    4668:    dcc00315     stw    r19,12(sp)
    466c:    dc800215     stw    r18,8(sp)
    4670:    dfc00415     stw    ra,16(sp)
    4674:    dc400115     stw    r17,4(sp)
    4678:    dc000015     stw    r16,0(sp)
    467c:    04c00044     movi    r19,1
    4680:    0025883a     mov    r18,zero
    4684:    10003226     beq    r2,zero,4750 <mpeg2_init+0xf0>
    4688:    000b883a     mov    r5,zero
    468c:    0111a004     movi    r4,18048
    4690:    00019bc0     call    19bc <_init+0xbc>   <---- here, we must relocate, but...
    4694:    01802004     movi    r6,128
    4698:    000b883a     mov    r5,zero
    469c:    10002426     beq    r2,zero,4730 <mpeg2_init+0xd0>

.

Of course, if these codes are linked as normal executables, these relocations will not make any troubles.

Kazu