* treatment of operands to .file/.appfile
@ 2005-04-19 15:25 Jan Beulich
0 siblings, 0 replies; 2+ messages in thread
From: Jan Beulich @ 2005-04-19 15:25 UTC (permalink / raw)
To: ian, nickc; +Cc: binutils
Nick, Ian,
wrt. the comments regarding file names in PR/847, I collected a pseudo-source file that indicates where (and how) file names would get altered with the current code. 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. If that seems undesirable to you, then working around this in ia64 (in order to make it work consistently with the Intel assembler, which is one of my current goals) may require quite intrusive changes elsewhere. I'm not really looking into fixing other architectures at present. If this seems like the right course of action, then I would to convert the below into a set of tests (one for each .file directive, since there seem to be varying opinions whether more than one such directive is valid in a single translation unit, and hence looking forward it might turn out the sequence of them could get rejected).
# delta (m68k sub-target)
.file "~tilde"
# ia64
.file "hash#"
# m68k
.opt nocase
.file "lower"
.file "UPPER"
# mmix
.file ":colon"
.prefix prefix
.file "/dir/file.s"
# ppc/xcoff
.file "[brackets]"
.file "{braces}"
# thumb (arm sub-target)
.file "slash/data"
# xtensa (through --rename-section file.s=file.c)
.file "file.s"
Jan
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: treatment of operands to .file/.appfile
[not found] <s26530fb.082@emea1-mh.id2.novell.com>
@ 2005-04-26 18:58 ` Nick Clifton
0 siblings, 0 replies; 2+ messages in thread
From: Nick Clifton @ 2005-04-26 18:58 UTC (permalink / raw)
To: Jan Beulich; +Cc: ian, binutils
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-04-26 17:36 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-19 15:25 treatment of operands to .file/.appfile Jan Beulich
[not found] <s26530fb.082@emea1-mh.id2.novell.com>
2005-04-26 18:58 ` Nick Clifton
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).