[PATCH] Deleting discardable stabs

[Alan Modra]

On Mon, Nov 12, 2001 at 10:28:08AM -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 13, 2001 at 12:22:31AM +1030, Alan Modra wrote:
> > On Sun, Nov 11, 2001 at 10:03:40PM -0500, Daniel Jacobowitz wrote:
> > > +
> > > +      if (! rcookie->bad_symtab)
> > > +	if (rcookie->rel->r_offset > offset)
> > > +	  return false;
> > 
> > Hmm, I guess it's reasonable to assume the relocs will always be sorted.
> > Assemblers other than gas?
> 
> My reading is that the relocs will be sorted unless elf_bad_symtab() is
> true.  Maybe that's not correct... I could read in the relocations and
> then sort them, I suppose.  Should I do that explicitly?

No, I don't think it worth doing unless someone can show a situation
where some other assembler emits relocs out of order.  That doesn't seem
likely, and "ld -r" keeps the relocs sorted too.

> > > +      if (rcookie->rel->r_offset != offset)
> > > +	continue;
> > > +
> > > +      rcookie->rel ++;
> > > +
> > > +      /* If rcookie->bad_symtab, we should check
> > > +	 finfo->sections[r_symndx] == NULL by analogy with
> > > +	 elf_link_input_bfd.  That's not available yet,
> > > +	 so we might miss some.  */
> > 
> > You do have the syms available, so could check binding.
> 
> Oh, OK.  My glance suggests that finfo->sections[r_symndx] == NULL here
> is equivalent to ELF_ST_BIND (isym->st_info) != STB_LOCAL; is that
> right?

Yes.

> > > +        {
> > > +          bfd_size_type amt = cookie.locsymcount * sizeof (Elf_External_Sym);
> > > +          cookie.locsyms = bfd_malloc (amt);
> > 
> > Need to free this somewhere.
> 
> A little further down:
> 	symtab_hdr->contents = (unsigned char *) cookie.locsyms
> 
> I was hoping that would take care of it, but while several things will
> use external symbols from symtab_hdr->contents, nothing else will set that
> for an input bfd.  My mistake.

Keeping them should certainly depend on info->keep_memory.  Since other
parts of the linker try to minimise memory usage by freeing local syms,
I think it would be better to unconditionally free them here, at least
until someone finds some statistics on linker memory usage.

Alan