The ia64 assembler is choking on `.file ""' with the error message "Zero-length symbol is illegal". According to the GAS manual this should be allowed. The problem is that gcc 3.4 and later now uses `.file ""' instead of `.file "<stdin>"' when input comes from stdin.
Subject: Re: New: Error: Zero-length symbol is illegal Hi Andreas, > The ia64 assembler is choking on `.file ""' with the error message > "Zero-length symbol is illegal". According to the GAS manual this should > be allowed. The problem is that gcc 3.4 and later now uses `.file ""' instead > of `.file "<stdin>"' when input comes from stdin. Hmm, well the documentation does also say that the feature is only supported for backwards compatibility and may go away in the future. Still a patch for this problem seems fairly straight forward. Jan, Ian - what do you think of this ? Cheers Nick gas/ChangeLog 2005-04-15 Nick Clifton <nickc@redhat.com> PR gas/847 * read.c (s_app_file): Call tc_convert_file_name, if defined, before s_app_file_string. * config/tc-ia64.c (ia64_convert_file_name): Define. Convert empty file names into "<stdin>". * config/tc-ia64.h (tc_convert_file_name): Define. Index: gas/config/tc-ia64.c =================================================================== RCS file: /cvs/src/src/gas/config/tc-ia64.c,v retrieving revision 1.152 diff -c -3 -p -r1.152 tc-ia64.c *** gas/config/tc-ia64.c 5 Apr 2005 04:01:12 -0000 1.152 --- gas/config/tc-ia64.c 15 Apr 2005 11:39:41 -0000 *************** ia64_canonicalize_symbol_name (name) *** 8031,8036 **** --- 8031,8049 ---- return name; } + /* Avoid producing error messages about zero-length symbol names when + GCC produces directives like: + .file "" + by converting empty names into <stdin>. */ + + char * + ia64_convert_file_name (char * name) + { + if (name != NULL && * name == 0) + return "<stdin>"; + return name; + } + /* Return true if idesc is a conditional branch instruction. This excludes the modulo scheduled branches, and br.ia. Mod-sched branches are excluded because they always read/write resources regardless of the value of the Index: gas/config/tc-ia64.h =================================================================== RCS file: /cvs/src/src/gas/config/tc-ia64.h,v retrieving revision 1.38 diff -c -3 -p -r1.38 tc-ia64.h *** gas/config/tc-ia64.h 3 Mar 2005 11:47:52 -0000 1.38 --- gas/config/tc-ia64.h 15 Apr 2005 11:39:41 -0000 *************** extern void ia64_dwarf2_emit_offset PARA *** 120,125 **** --- 120,126 ---- extern void ia64_check_label PARAMS ((symbolS *)); extern int ia64_estimate_size_before_relax (fragS *, asection *); extern void ia64_convert_frag (fragS *); + extern char * ia64_convert_file_name (char *); #define md_end() ia64_end_of_source () #define md_start_line_hook() ia64_start_line () *************** extern void ia64_convert_frag (fragS *); *** 132,137 **** --- 133,139 ---- #define md_parse_name(s,e,c) ia64_parse_name (s, e, c) #define tc_canonicalize_symbol_name(s) ia64_canonicalize_symbol_name (s) #define tc_canonicalize_section_name(s) ia64_canonicalize_symbol_name (s) + #define tc_convert_file_name(s) ia64_convert_file_name (s) #define md_optimize_expr(l,o,r) ia64_optimize_expr (l, o, r) #define md_cons_align(n) ia64_cons_align (n) #define TC_FORCE_RELOCATION(f) ia64_force_relocation (f)
I see two problems with this suggestion: The small one is that the change to read.c isn't shown. The larger one is that I don't think this is the right thing to do here. tc_canonicalize_symbol_name shouldn't be called in this context at all; even for non-zero length symbols it may do the wrong thing (for ia64 it removes trailing # symbols), whereas file names should remain untouched. Looking at how this gets called here, I see that save_symbol_name may do more bad to the filename (it may strip a leading _, and may also case-convert it). So it could either be save_symbol_name (or symbol_new) that would need to change (taking an additional parameter to indicate it should leave alone the symbol name), or elf_file_symbol would have to change the name of the symbol after having gone through symbol_new (and to address the problem brought up here, it could call symbol_new blindly with a literal string [say, "FILE"], preventing any issues with tc_canonicalize_symbol_name).
Subject: Re: New: Error: Zero-length symbol is illegal Nick Clifton <nickc@redhat.com> writes: > > The ia64 assembler is choking on `.file ""' with the error message > > "Zero-length symbol is illegal". According to the GAS manual this > > should be allowed. The problem is that gcc 3.4 and later now uses > > `.file ""' instead of `.file "<stdin>"' when input comes from stdin. > > Hmm, well the documentation does also say that the feature is only > supported for backwards compatibility and may go away in the future. > > Still a patch for this problem seems fairly straight forward. > > Jan, Ian - what do you think of this ? > > Cheers > Nick > > gas/ChangeLog > 2005-04-15 Nick Clifton <nickc@redhat.com> > > PR gas/847 > * read.c (s_app_file): Call tc_convert_file_name, if defined, > before s_app_file_string. > * config/tc-ia64.c (ia64_convert_file_name): Define. Convert > empty file names into "<stdin>". > * config/tc-ia64.h (tc_convert_file_name): Define. Why does ia64_canonicalize_symbol_name reject a symbol with no name? ELF permits them. Perhaps there are places which call canonicalize_symbol_name which want to reject empty symbol names, but I don't see why they should be rejected in canonicalize_symbol_name itself. Ian
Rejecting zero-length symbols could be undone, but I don't see the point; namely I can't see how you would ever use such a symbol (a standalone # operator is certainly illegal on ia64, and besides that ia64 has .alias to force "odd" symbol names that you can't normally express). Besides that, while addressing this PR, it wouldn't fix the other issue I mentioned.
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. It is fine with me if you want to reject symbols with no name in other places. You suggested that tc_canonicalize_symbol_name should not be called in this context. I don't agree. It should be called for every symbol name. Any other course of action is potentially confusing.
I just submitted a patch to undo the rejecting of zero-length symbol names; however, as said before, while this addresses the immediate issue reported here I continue to believe that stuff like .file "hash#" .file "_underscore" .file "UPPER" .file "lower" all should give consistent entries in the object file's symbol table, no matter what target architecture they're used on. Getting this right, however, requires avoiding save_symbol_name (or undoing its effects), implying avoiding/undoing any treatment tc_canonicalize_symbol_name might apply/have applied. (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 anthing 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 [leaving aside that certain file systems may only exist on certain architectures]).
ia64-specific patch applied to mainline; awaiting release manager approval for 2.16...
Also applied to 2.16.