But flag '-shared' and '-fpic' are used to create shared object, aren't they? When I use objdump to see the codes, I find that the program address doesn't start from 0. Such as, 5ffe065c <frame_dummy>: 5ffe065c: 3c020000 lui v0,0x0 5ffe0660: 27bdffe8 addiu sp,sp,-24 5ffe0664: 3c046002 lui a0,0x6002 5ffe0668: 3c056002 lui a1,0x6002 5ffe066c: 24420000 addiu v0,v0,0 5ffe0670: afbf0010 sw ra,16(sp) 5ffe0674: 248407a4 addiu a0,a0,1956 5ffe0678: 10400003 beqz v0,5ffe0688 <frame_dummy+0x2c> 5ffe067c: 24a508d8 addiu a1,a1,2264 5ffe0680: 0c000000 jal 50000000 <_init-0xffe0590> 5ffe0684: 00000000 nop 5ffe0688: 3c046002 lui a0,0x6002 5ffe068c: 8c8208a0 lw v0,2208(a0) 5ffe0690: 00000000 nop 5ffe0694: 10400007 beqz v0,5ffe06b4 <frame_dummy+0x58>
Why? And the symble 'b' is of absolute type(*A*)? 2006/2/23, Daniel Jacobowitz <[EMAIL PROTECTED]>: > On Thu, Feb 23, 2006 at 01:33:05PM +0800, Eric Fisher wrote: > > $ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps > > > > We can see this below from fun.s, > > lw $2,%gp_rel(b)($28) > > > > I think symble 'b' should be of GOT relocation. > > But it isn't. > > > > $ mips-elf-readelf -r fun.so > > There are no GOT relocations in shared libraries. They're resolved by > the linker. > > > I have no idea about the error and the symble 'b' of pic codes. > > Yet, when use this below > > $ mips-elf-as fun.s -call_shared -o fun.so > > > > $ mips-elf-readelf -r fun.so > > That's not a shared object, no matter what you call it. You have to > assemble and then link; please let GCC do the linking, it knows how > to invoke the linker properly for each platform. > > -- > Daniel Jacobowitz > CodeSourcery >
