From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6296 invoked by alias); 11 Nov 2004 06:13:57 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 5642 invoked from network); 11 Nov 2004 06:13:41 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 11 Nov 2004 06:13:41 -0000 Received: (qmail 30052 invoked by uid 10); 11 Nov 2004 06:13:40 -0000 Received: (qmail 2722 invoked by uid 500); 11 Nov 2004 06:13:32 -0000 Mail-Followup-To: binutils@sources.redhat.com, eagle_zhou@ali.com.tw From: Ian Lance Taylor To: eagle_zhou@ali.com.tw Cc: binutils@sources.redhat.com Subject: Re: the problem : assign the section's order in shared library based on mips platform References: Date: Thu, 11 Nov 2004 06:13:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00182.txt.bz2 eagle_zhou@ali.com.tw writes: > Yes, I am writing own dynamic loader/linker. And use our own operation > system. > > I have parsed all relocation info and generate my own data struct which > will be > resolved by my own dynamic loader/linker. > > So i do not need it's other info(string,symbol,and so on) again. > I only use it's text and data section. > > my aim is putting text and data section into continuous space and take out > them from .so file. > but now, i meet those problem i mentioned. If I were you I would rewrite the calling convention, including the GOT and the PLT, into something appropriate for your system. If you don't want to do that, then you will need to get a clear understanding of the current system. If I understood your question correctly, you are wondering why the stub code starts with the instruction lw t9,-32752(gp) In the current ELF support, MIPS stub code always starts with that instruction. The dynamic linker is responsible for filling that word with the address of the runtime resolution routine. The resolution routine will then fill in the GOT entry for the initial function (in your example, 140(gp)) so that future calls will bypass the stub entirely. One step you need to take if you want to go this path is to set _gp in your linker script. The linker will use that in calculating GP relocations (at least, that is how it used to work; I don't know whether there is a more intelligent way to set the GP value these days). Ian