From: Mark Mitchell <mark@codesourcery.com>
To: Richard Henderson <rth@redhat.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Link-time optimzation
Date: Thu, 17 Nov 2005 01:28:00 -0000 [thread overview]
Message-ID: <437BDC9E.3080608@codesourcery.com> (raw)
In-Reply-To: <20051117011900.GA17847@redhat.com>
Richard Henderson wrote:
In general, I'm going to just collect comments in a folder for a while,
and then try to reply once the dust has settled a bit. I'm interested
in seeing where things go, and my primary interest is in getting *some*
consensus, independent of a particular one.
But, I'll try to answer this:
> In Requirement 4, you say that the function F from input files a.o and
> b.o should still be named F in the output file. Why is this requirement
> more than simply having the debug information reflect that both names
> were originally F? I see you go to some length in section 3 to ensure
> actual symbol table duplicates, and I don't know why.
Our understanding was that the debugger actually uses the symbol table,
in addition to the debugging information, in some cases. (This must be
true when not running with -g, but I thought it was true in other cases
as well.) It might be true for other tools, too.
It's true that, from a correctness or code-generation point of view, it
shouldn't matter, so, for non-GNU assemblers, we could fall back to
F.0/F.1, etc.
> The rest of the requirements look good. I cannot immediately think of
> anything you've forgotten.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
next prev parent reply other threads:[~2005-11-17 1:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 22:26 Mark Mitchell
2005-11-16 22:41 ` Andrew Pinski
2005-11-16 22:58 ` Andrew Pinski
2005-11-17 0:02 ` Andrew Pinski
2005-11-17 0:25 ` Andrew Pinski
2005-11-17 0:52 ` Tom Tromey
2005-11-17 0:26 ` Giovanni Bajo
2005-11-17 0:32 ` Daniel Berlin
2005-11-17 9:04 ` Giovanni Bajo
2005-11-17 16:25 ` Kenneth Zadeck
2005-11-17 1:20 ` Richard Henderson
2005-11-17 1:28 ` Mark Mitchell [this message]
2005-11-17 1:31 ` Daniel Jacobowitz
2005-11-17 3:35 ` Jeffrey A Law
2005-11-17 14:09 ` Daniel Berlin
2005-11-17 14:48 ` mathieu lacage
2005-11-17 11:41 ` Richard Earnshaw
2005-11-17 21:40 ` Ian Lance Taylor
2005-11-17 23:10 ` Robert Dewar
2005-11-17 23:42 ` Ian Lance Taylor
2005-11-18 2:13 ` Daniel Jacobowitz
2005-11-18 9:29 ` Bernd Schmidt
2005-11-18 11:19 ` Robert Dewar
2005-11-18 11:29 ` Richard Earnshaw
2005-11-18 11:40 ` Directly generating binary code [Was Re: Link-time optimzation] Andrew Haley
2005-11-18 12:04 ` Laurent GUERBY
2005-11-18 17:41 ` Jim Blandy
2005-11-18 18:35 ` Link-time optimzation Mike Stump
2005-11-18 2:33 ` Dale Johannesen
2005-11-18 3:11 ` Geert Bosch
2005-11-18 18:43 ` Mike Stump
2005-11-18 18:30 ` Mike Stump
2005-11-17 15:54 ` Kenneth Zadeck
2005-11-17 16:41 ` Jan Hubicka
2005-11-18 16:31 ` Michael Matz
2005-11-18 17:04 ` Steven Bosscher
2005-11-18 17:29 ` Michael Matz
2005-11-18 17:24 ` Nathan Sidwell
2005-11-17 1:43 ` Gabriel Dos Reis
2005-11-17 1:53 ` Andrew Pinski
2005-11-17 2:39 ` Kean Johnston
2005-11-17 5:53 ` Ian Lance Taylor
2005-11-17 13:08 ` Ulrich Weigand
2005-11-17 21:42 ` Ian Lance Taylor
2005-11-17 16:17 ` Kenneth Zadeck
2005-11-17 0:52 Chris Lattner
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=437BDC9E.3080608@codesourcery.com \
--to=mark@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=rth@redhat.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).