RFH: How to find out wether the linker already has read a symbol table

RFH: How to find out wether the linker already has read a symbol table

[Björn Haase]

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.

Re: RFH: How to find out wether the linker already has read a symbol table

[Alan Modra]

On Mon, Apr 24, 2006 at 01:56:40AM +0200, Björn Haase wrote:
[about trampolines]

See bfd/elf32-hppa.c and ld/emultemp/hppaelf.em which implement a
superset of what you want.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre