question about pic and relocation

[Eric Fisher]

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 <drow@false.org>:
> 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
>