_bfd_elf_init_private_section_data setting output section type improperly for .stabstr

[H. J. Lu]

On Thu, May 11, 2006 at 02:24:07PM -0700, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > --- bfd/elf.c.stabs	2006-05-11 08:52:56.000000000 -0700
> > +++ bfd/elf.c	2006-05-11 09:26:36.000000000 -0700
> > @@ -5911,8 +5911,7 @@ _bfd_elf_init_private_section_data (bfd 
> >       output BFD section flags has been set to something different.
> >       elf_fake_sections will set ELF section type based on BFD
> >       section flags.  */
> > -  if (osec->flags == isec->flags
> > -      || (osec->flags == 0 && elf_section_type (osec) == SHT_NULL))
> > +  if (osec->flags == isec->flags || !osec->flags)
> >      elf_section_type (osec) = elf_section_type (isec);
> 
> This code does not make sense to me.  It assumes that a zero in the
> flags field means that the section flags have not been initialized.
> Why is that correct?

We are supposed to use bfd_make_section_anyway_with_flags and
bfd_make_section_with_flags if we need to set the section flags so that
_bfd_elf_new_section_hook can set up elf_section_type and
elf_section_flags properly. We can check if BFD section flags are
consistent with ELF section flags/type in
_bfd_elf_init_private_section_data. But it won't resolve all
consistency problems.

> 
> And, you seem to have ignored Nick's comments about this code here:
>     http://sourceware.org/ml/binutils/2006-04/msg00330.html
> 
> I think it is reasonable to want to make --set-section-flags work for
> ELF.  But I think that to do that we need to clearly separate the
> value that the flags hold from whether the flags hold any value at
> all.  Your patch seems to me to be quite fragile, and I'm not
> surprised that something broke.

The whole BFD is very fragile since we have both BFD section flags and
ELF section flags/type. I introduced bfd_make_section_anyway_with_flags
and bfd_make_section_with_flags, trying to address this issue. But I
missed stabs.c.


H.J.