Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: Klee Dienes <klee@apple.com>
Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Add stabs entries for coalesced symbols.
Date: Sun, 24 Nov 2002 09:46:00 -0000	[thread overview]
Message-ID: <m3isymj1va.fsf@gossamer.airs.com> (raw)
In-Reply-To: <F99ABA98-FF96-11D6-B9B6-00039396EEB8@apple.com>

Klee Dienes <klee@apple.com> writes:

> On Tuesday, November 19, 2002, at 01:23 AM, Ian Lance Taylor wrote:
> 
> > Coalesced symbols look quite similar to COMDAT sections (e.g.,
> > SEC_LINK_DUPLICATES_DISCARD).  They're called coalesced *symbols*, but
> > in BFD terminology they are really *sections*.  It would be nice if
> > you mentioned this in your new documentation.  Thanks.
> 
> My understanding is that coalesced symbols are similar to, but not
> quite the same as COMDAT sections.  In our implementation, coalesced
> symbols are placed into sections marked with the S_COALESCED flag,
> each of which may contain any number of coalesced symbols.  I've tried
> to make the documentation reflect this a bit better (speaking of
> which, I should mention that these docs are extensively plagiarized
> from docs written by another engineer at Apple; I'm just adapting them
> as best I can from the release notes for use in the stabs document).
> 
> Are you saying that our BFD Mach-O layer should be mapping each symbol
> in a Mach-O coalesced section into a separate BFD section flagged with
> SEC_LINK_DUPLICATES_DISCARD?  Unfortunately, we haven't yet extended
> our BFD layer to anything beyond that needed to support GDB and
> objdump/objcopy/etc., but it would be nice to know how to proceed for
> future reference.

I only intended to say that it would be nice if your documentation
mentioned COMDAT sections and SEC_LINK_DUPLICATES_DISCARD in
connection with coalesced symbols.  They are very similar (I do
understand the distinction you mention), and I believe it will help
people understand the documentation.

Ian


  parent reply	other threads:[~2002-11-24 17:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <C774777A-FB47-11D6-84AF-00039396EEB8@apple.com>
2002-11-18 16:37 ` Klee Dienes
2002-11-18 22:22   ` Ian Lance Taylor
2002-11-24  2:25     ` Klee Dienes
2002-11-24  6:21       ` Eli Zaretskii
2002-12-08 17:00         ` Klee Dienes
2002-12-08 22:39           ` Eli Zaretskii
2002-12-09 10:22             ` Klee Dienes
2002-12-09 12:37               ` Eli Zaretskii
2002-11-24  9:46       ` Ian Lance Taylor [this message]
2002-11-24 14:22       ` Jim Blandy
2002-12-06  8:59       ` Nick Clifton
2002-11-18 22:59 Eli Zaretskii
     [not found] <1038196445.11584.ezmlm@sources.redhat.com>
2002-11-24 20:21 ` Jim Ingham

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=m3isymj1va.fsf@gossamer.airs.com \
    --to=ian@airs.com \
    --cc=binutils@sources.redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=klee@apple.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