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
> 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 ?
2005-04-15 Nick Clifton <email@example.com>
* read.c (s_app_file): Call tc_convert_file_name, if defined,
* config/tc-ia64.c (ia64_convert_file_name): Define. Convert
empty file names into "<stdin>".
* config/tc-ia64.h (tc_convert_file_name): Define.
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 ----
+ /* 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
the modulo scheduled branches, and br.ia. Mod-sched branches are
because they always read/write resources regardless of the value
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
Subject: Re: New: Error: Zero-length symbol is illegal
Nick Clifton <firstname.lastname@example.org> 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 ?
> 2005-04-15 Nick Clifton <email@example.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
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
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
Also applied to 2.16.