From: Nick Clifton <nickc@redhat.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: ian@airs.com, binutils@sources.redhat.com
Subject: Re: treatment of operands to .file/.appfile
Date: Tue, 26 Apr 2005 18:58:00 -0000 [thread overview]
Message-ID: <426E7BBA.6080607@redhat.com> (raw)
In-Reply-To: <s26530fb.082@emea1-mh.id2.novell.com>
Hi Jan,
[Sorry for not replying to this email sooner].
> I'd like to come to an agreement on how gas should deal with this;
> as I stated in the PR I think file names should not be altered
> independent of the target.
I agree with you on this.
But, I also agree with Ian when he says:
: My point is that symbols like the STT_FILE symbol or STT_SECTION
: symbols do not need to have a name. It is not a bug to have a
: symbol with no name. The macro tc_canonicalize_symbol_name
: applies to all symbols. That macro should not reject symbols
: with no name.
I actually think that the right answer is to modify
tc_canonicalize_symbol_name so that it is given a context for the
symbol. You said:
> Alternatively, tc_canonicalize_symbol_name could be given a way
> to know it's dealing with a file name, so as to allowing it to
> decide whether do do anything special here, but I don't think
> that'd be the right solution; after all, file names only depend
> on file system conventions, not on processor architecture
Which is precisely why I think that tc_canonicalize_symbol_name should
be given an extra parameter, one which says "this symbol should be made
to be valid in a host-system context" or "this symbol should be made to
be valid in a target-architecture context". [This could be extended to
other contexts if necessary].
Cheers
Nick
next parent reply other threads:[~2005-04-26 17:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <s26530fb.082@emea1-mh.id2.novell.com>
2005-04-26 18:58 ` Nick Clifton [this message]
2005-04-19 15:25 Jan Beulich
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=426E7BBA.6080607@redhat.com \
--to=nickc@redhat.com \
--cc=JBeulich@novell.com \
--cc=binutils@sources.redhat.com \
--cc=ian@airs.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).