Re: PR ld/3107

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Oct 18, 2006 at 01:07:33AM +0930, Alan Modra wrote:
> On Fri, Sep 15, 2006 at 11:01:25PM +0930, Alan Modra wrote:
> > On Fri, Sep 15, 2006 at 09:48:58AM -0000, nickc@sourceware.org wrote:
> > > Log message:
> > > 	PR ld/3107
> > > 	* ldlang.c (lang_size_sections_1): Do not abort when encountering a non-empty
> > > 	section that is ignored.  Instead produce a warning message.
> > 
> > Eh?  Something is fishy here
> 
> I believe this is how arm should handle its glue sections.  (Or at
> least, this is a minimal change.)  There were two bugs leading to
> PR ld/3107:  The most serious one (I think I introduced with the initial
> attempt at stripping unused sections) was to run the standard
> ELF linker before_allocation function too early, before
> bfd_elf32_arm_process_before_allocation had a chance to size the glue
> sections.  The other was that record_arm_to_thumb_glue and
> record_thumb_to_arm_glue were not updating the actual glue section sizes.
> Even if the glue section sizes were calculated early enough the
> generic linker saw them as being zero size at the time empty sections
> were stripped.  This meant their output section could be marked
> "ignored", but later found to not in fact be empty.

One problem: adjust_dynamic_symbol is called from
gld${EMULATION_NAME}_before_allocation.  That changes from the
plt.refcount notation to plt.offset.  But during
bfd_elf32_arm_process_before_allocation we want to determine which
functions will be called via the PLT, and we do that by checking
plt.offset.  So now we don't create glue for Thumb to ARM calls
even when we need it.  The resulting binaries are full of infinite
loops.

Do I have to duplicate the logic to determine whether a symbol will get
a PLT entry?  It's rather too convoluted to move it out of
adjust_dynamic_symbol.

The standard linker allocation functions did not start being run
earlier in your previous attempt at stripping unused sections, unless
you meant something before the dawn of sourceware.org CVS - I went back
as far as revision 1.2, and things start getting confused during the
vendor imports.

I'm too tired to work through this right now; any comments appreciated.
I don't see how we can determine which functions need glue this early.

-- 
Daniel Jacobowitz
CodeSourcery