Re: treatment of operands to .file/.appfile

Re: treatment of operands to .file/.appfile

[Nick Clifton]

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

treatment of operands to .file/.appfile

[Jan Beulich]

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