This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RFH: How to find out wether the linker already has read a symbol table
- From: BjÃrn Haase <bjoern dot m dot haase at web dot de>
- To: binutils at sourceware dot org
- Date: Mon, 24 Apr 2006 01:56:40 +0200
- Subject: RFH: How to find out wether the linker already has read a symbol table
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.