PATCH: Fix the relax finalize pass

[H. J. Lu]

On Wed, May 14, 2003 at 06:01:25PM -0700, Richard Henderson wrote:
> 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.

It sounds good. Are you going to implement it? If not, I will give it
a try.


H.J.