This is the mail archive of the
mailing list for the binutils project.
Re: _bfd_elf_init_private_section_data setting output section type improperly for .stabstr
On Thu, May 11, 2006 at 02:24:07PM -0700, Ian Lance Taylor wrote:
> "H. J. Lu" <firstname.lastname@example.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
> And, you seem to have ignored Nick's comments about this code here:
> 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