This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Linking non-PIC modules with PIC modules for MIPS SVR4.2MP
- From: "Kai Ruottu" <kai_ruottu at mbnet dot fi>
- To: binutils at sources dot redhat dot com
- Date: Fri, 15 Feb 2002 15:16:23 +0000
- Subject: Linking non-PIC modules with PIC modules for MIPS SVR4.2MP
- Organization: MBinternet
- Reply-to: kai_ruottu at mbnet dot fi
On NEC's EWS4800 the provided 'shared' libs in '/usr/abiccs/lib' are partly made
of non-PIC modules ('crt*.o', some separate modules inside 'libc.so') and of real
PIC-mode shared libs. My problem is to produce a cross-toolkit for this weird
'mips-nec-sysv4.2MP' stuff using the GNU binutils...
The native linker can mix the modules using wrapper-switches '-Znocount'
and '-Zcount' around the 'non-PIC' stuff :
---------
/usr/local/lib/gcc-lib/mips-nec-sysv4.2MP/2.95.2/collect2 -dy -o chap26_9
-Znocount /usr/abiccs/lib/crt1.o /usr/abiccs/lib/crti.o -Zcount
-L/usr/local/lib/gcc-lib/mips-nec-sysv4.2MP/2.95.2
-L/usr/local/mips-nec-sysv4.2MP/lib
-L/usr/abiccs/bin -L/usr/abiccs/lib -L/usr/local/lib
/var/tmp/ccjzUkrt.o -lstdc++ -lm
-lgcc
-Znocount -lc /usr/abiccs/lib/crtn.o /usr/abiccs/lib/values-Xt.o -Zcount
-lgcc
---------
but trying the '-Bstatic' and '-Bdynamic' for the same 'non-PIC'/'PIC'-mixing
with GNU ld doesn't work. It tells that it still cannot mix the PIC- and non-PIC
stuff... Is there any way to do this mixing?
The seen workarounds are to use the fully-PIC shared '/usr/lib/libc.so.1'
as the C-library to link with at the link-time and to try to reverse-engineer the
'crt*.o' stuff and to duplicate them as 'PIC'-mode modules....
When trying 'free crt*.o's made from a modified 'start.c' from glibc etc., resulted
to the situation that the linked C programs (like cross-built native binutils-2.11.2)
seem to work fine, but all the C++ programs silently die... BTW, the simple tried
C++ tests seem to need only the 'modff()' from the separate non-PIC modules
inside the original 'libc.so'. Both newlib and glibc-2.x give the 's_modf(f).c' for
replacing the original...
The 'free crt1.o' tried was originally tested to work for another 'mips-sysv4.2', which
was using purely PIC-stuff everywhere. But it has missing some calls to some
routines like 'zeromem()' in the original non-PIC 'crt1.o'. This might cause the C++
programs to die, so I would like to try to better it...
Here comes the problem with 'objdump -d'... It doesn't seem to use the symbol
table in the module for anything... The called functions and data addresses are
named only as '0 <_start>' and '0x0' in the disassembly although the symbol table
should have some connection to the code :
H:\usr\local\mips-nec-sysv4.2MP\lib\non-pic>..\..\bin\objdump -d crt1.o
crt1.o: file format elf32-tradbigmips
Disassembly of section .text:
00000000 <_start>:
0: 3c1c0000 lui gp,0x0
4: 279c0000 addiu gp,gp,0
8: 27bdffe0 addiu sp,sp,-32
c: afbf0018 sw ra,24(sp)
10: 3c040000 lui a0,0x0
14: afa2001c sw v0,28(sp)
18: 0c000000 jal 0 <_start> <--- What is the function called ?
1c: 24840000 addiu a0,a0,0
20: 8fa2001c lw v0,28(sp)
24: 00000000 nop
28: 10400003 beqz v0,38 <_start+0x38>
2c: 00000000 nop
30: 0c000000 jal 0 <_start> <--- What is the function called ?
34: 00402021 move a0,v0
38: 3c040000 lui a0,0x0
3c: 0c000000 jal 0 <_start> <--- What is the function called ?
40: 24840000 addiu a0,a0,0
44: 0c000000 jal 0 <_start> <--- What is the function called ?
48: 00000000 nop
4c: 8fa40020 lw a0,32(sp)
50: 27a50024 addiu a1,sp,36
54: 24a60004 addiu a2,a1,4
58: 00041080 sll v0,a0,0x2
5c: 00c23021 addu a2,a2,v0
60: 3c010000 lui at,0x0 <--- Some address loaded
64: ac260000 sw a2,0(at)
68: 3c010000 lui at,0x0 <--- Some address loaded
6c: ac240000 sw a0,0(at)
70: 3c010000 lui at,0x0 <--- Some address loaded
74: ac250000 sw a1,0(at)
78: 0c000000 jal 0 <_start> <--- Some function called
7c: afa0001c sw zero,28(sp)
80: 3c040000 lui a0,0x0 <--- Some address loaded
84: 3c050000 lui a1,0x0 <--- Some address loaded
88: 3c060000 lui a2,0x0 <--- Some address loaded
8c: 8c840000 lw a0,0(a0)
90: 8ca50000 lw a1,0(a1)
94: 8cc60000 lw a2,0(a2)
98: 0c000000 jal 0 <_start> <--- Some function called
9c: 00000000 nop
a0: 0c000000 jal 0 <_start> <--- Some function called
a4: 00402021 move a0,v0
a8: 0000000d break
ac: 03e00008 jr ra
b0: 00000000 nop
000000b4 <__trapuv>:
b4: 24080800 li t0,2048
b8: 44c8f800 ctc1 t0,ra
bc: 03e00008 jr ra
c0: 00000000 nop
000000c4 <_mcount>:
c4: 27bd0008 addiu sp,sp,8
c8: 03e00008 jr ra
cc: 0020f821 move ra,at
H:\usr\local\mips-nec-sysv4.2MP\lib\non-pic>..\..\bin\objdump -t crt1.o
crt1.o: file format elf32-tradbigmips
SYMBOL TABLE:
00000000 l df *ABS* 00000000 crt1.o
00000000 l d .reginfo 00000000
00000000 l d .text 00000000
00000000 l d .note 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l d .comment 00000000
00000000 l df *ABS* 00000000 ../../src/crt1_text.s
00000000 l O *ABS* 00000000 STARTFRM
00000000 l df *ABS* 00000000 /home/sgsenv/usr/abiccs/include/sys/regdef.h
00000000 l df *ABS* 00000000 /home/sgsenv/usr/src/cmplrs/cc2.20/include/sys/
asm.h
00000000 l df *ABS* 00000000 ../../src/crt1_data.s
00000000 O *UND* 00000000 _fini
00000000 O *UND* 00000000 main
00007ff0 g O *ABS* 00000000 _gp
00000000 O *UND* 00000000 _cleanup
00000000 g F .text 00000000 _start
00000000 O *UND* 00000000 _environ
00000000 O *UND* 00000000 atexit
00000000 O *UND* 00000000 __zeromem
00000004 O *COM* 00000004 __Argc
00000004 O *COM* 00000004 __Argv
00000000 O *UND* 00000000 exit
000000b4 g F .text 00000000 __trapuv
000000c4 g F .text 00000000 _mcount
00000000 O *UND* 00000000 _init
Is there any way to see the called function names and the names for the addresses
in the disassembly listing? Then cloning the current non-PIC 'crt1.o' could be a little
more easy...
But if looking at the beginning of the startup, it looks having the tinkering
with 'gp' as if it being a PIC-file... But 'readelf -h' claims it isn't... Is here only a wrong
flag in the file header?
Anyway if the original non-PIC/PIC stuff could be used with the GNU ld, that would be
best... Is there some way to do this now ? For instance using the native linker etc. to
convert the non-PIC stuff into PIC-stuff. This seems to happen now -- when looking
with 'objdump -d' at the natively linked executable, the '_start' etc. stuff there is in
PIC-mode and the whole executable is in the required PIC-mode...
The access to the target machine has been limited, so just trying all kind of things
isn't that easy.... So I ask it here if someone has tried something equal...
Many thanks in advance... Kai