From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22060 invoked by alias); 24 Apr 2006 10:13:53 -0000 Received: (qmail 22035 invoked by uid 22791); 24 Apr 2006 10:13:50 -0000 X-Spam-Check-By: sourceware.org Received: from fmmailgate01.web.de (HELO fmmailgate01.web.de) (217.72.192.221) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Apr 2006 10:13:47 +0000 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id A66D62308201 for ; Mon, 24 Apr 2006 12:08:57 +0200 (CEST) Received: from [84.161.168.252] (helo=[192.168.1.2]) by smtp08.web.de with esmtp (WEB.DE 4.107 #108) id 1FXy01-0001Dt-00 for binutils@sourceware.org; Mon, 24 Apr 2006 12:08:57 +0200 From: =?utf-8?q?Bj=C3=B6rn_Haase?= To: binutils@sourceware.org Subject: RFH: How to find out wether the linker already has read a symbol table Date: Mon, 24 Apr 2006 18:22:00 -0000 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604240156.40113.bjoern.m.haase@web.de> X-Sender: bjoern.m.haase@web.de Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00320.txt.bz2 Hi, I'm having some questions concerning bfd's interna. In order to make the issue more transparent, here is the Background story: I am working on support for a new family of AVR devices that has 24 bit PC in contrast to the 16 bit PC of the other devices. Since we whish to continue using 16 bit pointers for these devices, we have to introduce trampoline stubs in the lower memory area in case that we are trying to use 16 bit relocs with lables beyond the 16bit boundary. Since the lables could be local and global lables and since the affected reloc's addend could be different from zero, it's not a cut-and-paste from, e.g. the hc11 port. My plan for realizing the trampoline generation is to 1.) Introduce a dummy bfd input file. 2.) Add a .trampolines section in this dummy input bfd. 3.) Calculate the number of distinct destinations for obtaining an estimate. 4.) Set the size of the .trampoline section to the maximum size prior to allocation. 5.) Let the allocation do it's work. 6.) Re-investigate the number of necessary stubs (considering that some of the reloc destination already ended up below the 16 bit boundary) and re-adjust the .trampoline section size. 7.) Generate the trampolines and change the affected 16 bits relocs to point to the trampoline instead. When relaxing, Step 6) would be executed more frequently. Step 1), 2) and 4) are a cut-and paste from the hc11 port. 7) is straight-forward as well. The issue where I am feeling uneasy about is 3) and 6). What I will be needing to do is to process all of the relocs in all of the input sections of all of the input bfds in order to find out all distinct destinations of the 16 bits relocs. In principle each reloc will contain a pointer to a pointer to the relevant symbol. I am, however, not sure if I could always assume that if the reloc is already in memory, all of the other bfd's symbol tables and symbol informations is present as well. Possibly it will be necessary to explicitly load the symbol tables? So the question A) is A) If I am having "arelent" with a pointer to a pointer to a symbol, could I assume that the symbol's table is in memory? Also the symbols will be refering to the corresponding section or to the absolute section. One would have to distinguish these two cases. Thus question B): B) Is there some kind of function that takes a pointer to a symbol and returns the actual value of the symbol for the present position of the section. The third question is then. C) Is there a way to find out, wether or not allocation has already started, so that the section start values actually have a correct value? Because prior to the first allocation, one would have to be very conservative about the estimated size of the .trampoline section. Before an attempt of allocation, we will have to assume that all of the destinations will require the insertion of a trampoline since any destination possibly is out of reach of a 16 bit reloc. I'd really appreciate some support or general hints on the issue -). Bjoern.