From: "H. J. Lu" <hjl@lucon.org>
To: Zack Weinberg <zack@codesourcery.com>, binutils@sources.redhat.com
Subject: Re: PATCH: Multiple sections with same name don't work
Date: Sat, 01 May 2004 17:31:00 -0000 [thread overview]
Message-ID: <20040501173108.GA3367@lucon.org> (raw)
In-Reply-To: <20040501153720.GB1252@lucon.org>
On Sat, May 01, 2004 at 08:37:20AM -0700, H. J. Lu wrote:
> On Sun, May 02, 2004 at 12:14:39AM +0930, Alan Modra wrote:
> > On Sat, May 01, 2004 at 12:06:18AM -0700, H. J. Lu wrote:
> > > On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
> > > > On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> > > > > Alan Modra <amodra@bigpond.net.au> writes:
> > > > > > The real question is: Do we need multiple sections of the same name
> > > > > > in assembly files? I don't think we do.
> > > > >
> > > > > I need them in order to generate COMDAT sections compatible with the
> > > > > HPUX linker. gcc might emit e.g.
> > > > >
> > > > > .section .text
> > > > > # non-COMDAT code ...
> > > > >
> > > > > .section .text,"G",symbol_name,comdat
> > > > > # code for symbol_name ...
> >
> > Hmm, it wouldn't be much harder to use
> >
> > .section .text.symbol_name,"G",symbol_name,comdat
> > # code for symbol_name ...
> >
> > I fear HJ is going to be repeating the following a few more times..
> >
>
> I am ready for it.
>
> > > This patch is not enough. Here is an updated one.
> >
> > [snip]
> > > + /* Don't reset it if it is already a BFD section symbol. */
> > > + if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
> > > + s->bsym = bsym;
>
> This patch is no longer needed for multiple section with the same
> name. The section_symbol patch is enough.
>
> >
> > This is a useless comment. It just says what anyone can see from the
> > next line of code. It would be better to say _why_ it is necessary to
> > treat section symbols specially.
> >
>
> Since now we create multiple symbols with the same name, I think
> we need a new interface to lookup symbols with matching section.
>
>
I was wrong on both. We don't need a new interface for symbol lookup.
Also we do need the symbol_set_bfdsym change.
H.J.
----
2004-05-01 H.J. Lu <hongjiu.lu@intel.com>
* subsegs.c (section_symbol): Create a new section symbol if
the existing one doesn't match.
* symbols.c (symbol_set_bfdsym): Don't reset BFD section symbol.
--- gas/subsegs.c.same 2003-12-04 10:43:25.000000000 -0800
+++ gas/subsegs.c 2004-05-01 09:13:31.000000000 -0700
@@ -524,7 +524,9 @@ section_symbol (segT sec)
else
{
s = symbol_find_base (sec->symbol->name, 0);
- if (s == NULL)
+ /* We have to make sure it is the right symbol when we have
+ multiple sections with the same section name. */
+ if (s == NULL || S_GET_SEGMENT (s) != sec)
s = symbol_new (sec->symbol->name, sec, 0, &zero_address_frag);
else
{
--- gas/symbols.c.same 2004-05-01 07:55:53.000000000 -0700
+++ gas/symbols.c 2004-05-01 10:11:31.000000000 -0700
@@ -2260,7 +2260,15 @@ symbol_set_bfdsym (symbolS *s, asymbol *
{
if (LOCAL_SYMBOL_CHECK (s))
s = local_symbol_convert ((struct local_symbol *) s);
- s->bsym = bsym;
+ /* Usually, it is harmless to reset a symbol to a BFD section
+ symbol. For example, obj_elf_change_section sets the BFD symbol
+ of an old symbol with the newly created section symbol. But when
+ we have multiple sections with the same name, the newly created
+ section may have the same name as an old section. We check if the
+ old symbol has been already marked as a section symbol before
+ resetting it. */
+ if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
+ s->bsym = bsym;
}
#endif /* BFD_ASSEMBLER */
next prev parent reply other threads:[~2004-05-01 17:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-30 22:31 H. J. Lu
[not found] ` <20040430230129.GA17907@lucon.org>
2004-05-01 0:36 ` PATCH: " H. J. Lu
2004-05-01 2:31 ` Alan Modra
2004-05-01 2:59 ` Alan Modra
2004-05-01 3:43 ` H. J. Lu
2004-05-01 4:25 ` Alan Modra
2004-05-01 4:34 ` H. J. Lu
2004-05-01 5:12 ` Zack Weinberg
2004-05-01 5:50 ` H. J. Lu
2004-05-01 7:06 ` H. J. Lu
2004-05-01 14:44 ` Alan Modra
2004-05-01 15:37 ` H. J. Lu
2004-05-01 17:31 ` H. J. Lu [this message]
2004-05-01 18:42 ` Zack Weinberg
2004-05-01 7:08 ` H. J. Lu
2004-05-11 15:57 Nick Clifton
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=20040501173108.GA3367@lucon.org \
--to=hjl@lucon.org \
--cc=binutils@sources.redhat.com \
--cc=zack@codesourcery.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).