This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: Fix the relax finalize pass
- From: Richard Henderson <rth at redhat dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com, amodra at bigpond dot net dot au, jakub at redhat dot com
- Date: Wed, 14 May 2003 18:01:25 -0700
- Subject: Re: PATCH: Fix the relax finalize pass
- References: <20030513163647.B21871@lucon.org> <20030514075330.GC16863@redhat.com> <20030514155346.A9453@lucon.org>
On Wed, May 14, 2003 at 03:53:46PM -0700, H. J. Lu wrote:
> * ldlang.c (lang_size_sections_1): Take one more argument to
> indicate if the relax finalize pass is needed.
> (lang_size_sections): Updated.
> (lang_process): Likewise.
> * ldlang.h (lang_size_sections_1): Likewise.
> * pe-dll.c (pe_dll_fill_sections): Likewise.
> (pe_exe_fill_sections): Likewise.
> * emultempl/elf32.em (gld${EMULATION_NAME}_finish): Likewise.
> * emultempl/hppaelf.em (hppaelf_layout_sections_again): Likewise.
> * emultempl/ppc64elf.em (ppc_before_allocation): Likewise.
> (ppc_layout_sections_again): Likewise.
>
> * ldlang.c (lang_size_sections): Don't adjust data segment
> address after the relax finalize pass starts.
> (lang_process): Perform the relax finalize pass only when
> needed. Finalize addresses before the relax finalize pass.
Ug. This is becoming gross.
I think the proper way to handle this is to break up the relax
pass in bfd so that the backend gets more control.
(1) We need a "beginning of new pass" hook that is called
after sizes are guessed and addresses are assigned.
This is where we'd assign a new GP if needed.
We'd like for this to be able to allocate a data structure
private to the backend, so that the pieces and passes can
communicate.
(2) Existing relax hook operates on each section as usual.
It records information into the private data structure
as needed.
(3) An "end of pass" hook that is called after all sections
are processed. Using data collected from sections it
may decide to re-layout the GOT, or adjust dynamic
relocations or whatever. Currently we do this kind of
thing for every section, which wastes time.
If this "end of pass" hook returns "no more iterations",
then it is also the case that the private data has been
deallocated.
Operation for ia64 would indeed pass through two phases, one
in which we expand code by adding trampolines, and one in which
we shrink data by eliminating got entries. But all this would
be controlled by the backend, and all lang_size_sections knows
is that it's been told to continue around the relaxation loop.
As a side benefit, ia64 would get to keep track of the
trampolines that it has added between sections and iterations,
so that they can be re-used when they're in range.
r~