This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: treatment of operands to .file/.appfile
- From: Nick Clifton <nickc at redhat dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: ian at airs dot com, binutils at sources dot redhat dot com
- Date: Tue, 26 Apr 2005 18:34:50 +0100
- Subject: Re: treatment of operands to .file/.appfile
- References: <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