From: "H. J. Lu" <hjl@lucon.org>
To: Ian Lance Taylor <iant@google.com>
Cc: Mike Bland <mbland@google.com>, binutils@sourceware.org
Subject: Re: _bfd_elf_init_private_section_data setting output section type improperly for .stabstr
Date: Mon, 15 May 2006 09:32:00 -0000 [thread overview]
Message-ID: <20060514214605.GA31290@lucon.org> (raw)
In-Reply-To: <m31wv0uufc.fsf@dhcp-172-24-108-235.corp.google.com>
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.
next prev parent reply other threads:[~2006-05-14 21:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 12:24 Mike Bland
2006-05-11 15:55 ` Alan Modra
2006-05-11 22:21 ` H. J. Lu
2006-05-11 23:18 ` H. J. Lu
2006-05-12 2:14 ` Ian Lance Taylor
2006-05-15 9:32 ` H. J. Lu [this message]
2006-06-01 4:02 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060514214605.GA31290@lucon.org \
--to=hjl@lucon.org \
--cc=binutils@sourceware.org \
--cc=iant@google.com \
--cc=mbland@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).