[Bug ld/815] [C-api -> C++ lib] undefined symbol _Unwind*
--- Additional Comments From pluto at pld-linux dot org 2005-04-15 07:20 --- (In reply to comment #11) full link command: /usr/bin/ld --eh-frame-hdr -m elf_i386 -shared -o .libs/wmfthumbnail.so -z combreloc -L/usr/lib/gcc/i686-pld-linux/4.0.0 -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdefx/.libs -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/dcop/.libs -L/usr/lib/gcc/i686-pld-linux/4.0.0/../../.. -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdecore/.libs -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kwallet/client/.libs -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdesu/.libs -L/home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdeui/.libs -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/gcc/i686-pld-linux/4.0.0 -L/usr/lib/gcc/i686-pld-linux/4.0.0 -L/usr/lib/gcc/i686-pld-linux/4.0.0/../../.. --as-needed --no-undefined --allow-shlib-undefined /usr/lib/gcc/i686-pld-linux/4.0.0/../../../crti.o /usr/lib/gcc/i686-pld-linux/4.0.0/crtbeginS.o .libs/wmfthumbnail_la.all_cpp.o ../kio/.libs/libkio.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdeui/.libs/libkdeui.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdesu/.libs/libkdesu.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kwallet/client/.libs/libkwalletclient.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdecore/.libs/libkdecore.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/dcop/.libs/libDCOP.so -lresolv -lutil /usr/lib/libart_lgpl_2.so /usr/lib/libidn.so /home/users/pluto/rpm/BUILD/kdelibs-3.4.0/kdefx/.libs/libkdefx.so /usr/lib/libqt-mt.so -lGL -lXmu -lXrandr -lXcursor -lXinerama -lXft /usr/lib/libfontconfig.so -ldl -lXext -lpthread -lXrender /usr/lib/libfam.so /usr/lib/libwmf.so /usr/lib/libwmflite.so /usr/lib/libfreetype.so -lSM -lICE -lX11 /usr/lib/libexpat.so /usr/lib/libjpeg.so -lpng -lz /usr/lib/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc/i686-pld-linux/4.0.0/crtendS.o /usr/lib/gcc/i686-pld-linux/4.0.0/../../../crtn.o -soname wmfthumbnail.so grep results: /lib/libc-2.3.90.so 1942 838: 000dc03349FUNC GLOBAL DEFAULT 11 pthread_mutex_init /lib/libpthread-2.3.90.so 297 226: 6c4467FUNC GLOBAL DEFAULT 12 pthread_mutex_init 92 341: 6c4467FUNC GLOBAL DEFAULT 12 __pthread_mutex_init /usr/lib/libqt-mt.so 6936 14053: 67FUNC WEAK DEFAULT UND pthread_mutex_init /usr/X11R6/lib/libGL.so 692 526: 67FUNC GLOBAL DEFAULT UND pthread_mutex_init /usr/X11R6/lib/libX11.so 432 526: 49FUNC GLOBAL DEFAULT UND pthread_mutex_init reduced testcase is: /usr/bin/ld --eh-frame-hdr -m elf_i386 -shared -o wmfthumbnail.so \ --no-undefined --allow-shlib-undefined --as-needed \ ./wmfthumbnail_la.all_cpp.o \ /usr/lib/libqt-mt.so /lib/libpthread.so.0 /usr/X11R6/lib/libX11.so \ -soname wmfthumbnail.so without --as-needed option it reports only valid undefined references. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=815 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/850] linker issued assertion failure elf64-ppc.c:7771
--- Additional Comments From nickc at redhat dot com 2005-04-15 10:49 --- Subject: Re: New: linker issued assertion failure elf64-ppc.c:7771 Hi Robert, > The problem caught is about error during linking of executable. > /usr/bin/ld: BFD 041202 20041202 assertion fail elf64-ppc.c:7771 Please could you provide a simple way to reproduce this problem. > This error msg is repeated many times. > ld -V > GNU ld version 041202 20041202 You may find that a newer version of the linker has fixed this problem. Would you care to try the current sources in the binutils CVS repository ? Cheers Nick -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=850 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/850] New: linker issued assertion failure elf64-ppc.c:7771
Hi Robert, The problem caught is about error during linking of executable. /usr/bin/ld: BFD 041202 20041202 assertion fail elf64-ppc.c:7771 Please could you provide a simple way to reproduce this problem. This error msg is repeated many times. ld -V GNU ld version 041202 20041202 You may find that a newer version of the linker has fixed this problem. Would you care to try the current sources in the binutils CVS repository ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/815] [C-api -> C++ lib] undefined symbol _Unwind*
--- Additional Comments From amodra at bigpond dot net dot au 2005-04-15 11:16 --- I've traced what is happening, and everything now makes sense. This fix checked in to mainline and 2.16 should cure your problem. PR ld/815 * elflink.c (elf_smash_syms): Clear undef.next if it's not being used as a list pointer. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=815 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/847] 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 ""' 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 <[EMAIL PROTECTED]>
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 "".
* 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.c5 Apr 2005 04:01:12 - 1.152
--- gas/config/tc-ia64.c15 Apr 2005 11:39:41 -
*** 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 . */
+
+ char *
+ ia64_convert_file_name (char * name)
+ {
+ if (name != NULL && * name == 0)
+ return "";
+ 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 - 1.38
--- gas/config/tc-ia64.h 15 Apr 2005 11:39:41 -
*** 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)
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/847] Error: Zero-length symbol is illegal
--- Additional Comments From nickc at redhat dot com 2005-04-15 11:46
---
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 ""' 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 <[EMAIL PROTECTED]>
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 "".
* 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.c5 Apr 2005 04:01:12 - 1.152
--- gas/config/tc-ia64.c15 Apr 2005 11:39:41 -
*** 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 . */
+
+ char *
+ ia64_convert_file_name (char * name)
+ {
+ if (name != NULL && * name == 0)
+ return "";
+ 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.h3 Mar 2005 11:47:52 - 1.38
--- gas/config/tc-ia64.h15 Apr 2005 11:39:41 -
*** 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)
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=847
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/815] [C-api -> C++ lib] undefined symbol _Unwind*
--- Additional Comments From amodra at bigpond dot net dot au 2005-04-15
11:19 ---
libqt-mt.so.3.3.4 defines [EMAIL PROTECTED]
$22 = {root = {root = {next = 0x85d2380,
string = 0x85a9ea0 "[EMAIL PROTECTED]", hash = 421875337},
type = bfd_link_hash_undefweak, u = {undef = {next = 0x0,
abfd = 0x85890e8, weak = 0x85890e8}, def = {next = 0x0,
section = 0x85890e8, value = 140021992}, i = {next = 0x0,
link = 0x85890e8, warning = 0x85890e8 "\002"}, c = {next = 0x0,
p = 0x85890e8, size = 140021992}}}, indx = -1, dynindx = -1, got = {
refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0,
offset = 0, glist = 0x0, plist = 0x0}, size = 0, type = 0, other = 0,
ref_regular = 0, def_regular = 0, ref_dynamic = 0, def_dynamic = 0,
ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0,
needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, mark = 0,
non_got_ref = 0, dynamic_def = 0, dynamic_weak = 0,
pointer_equality_needed = 0, dynstr_index = 0, u = {weakdef = 0x0,
elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0},
vtable = 0x0}
libqt-mt.so.3.3.4 is needed, so above is kept.
libpthread.so.0 defines pthread_mutex_init@@GLIBC_2.0
$25 = {root = {root = {next = 0x865fa24,
string = 0x876b230 "pthread_mutex_init@@GLIBC_2.0", hash = 329801547},
type = bfd_link_hash_defined, u = {undef = {next = 0x0, abfd = 0x85be3a4,
weak = 0x2700}, def = {next = 0x0, section = 0x85be3a4,
value = 9984}, i = {next = 0x0, link = 0x85be3a4,
warning = 0x2700 }, c = {next = 0x0,
p = 0x85be3a4, size = 9984}}}, indx = -1, dynindx = -1, got = {
refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0,
offset = 0, glist = 0x0, plist = 0x0}, size = 0, type = 0, other = 0,
ref_regular = 0, def_regular = 0, ref_dynamic = 0, def_dynamic = 0,
ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0,
needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, mark = 0,
non_got_ref = 0, dynamic_def = 0, dynamic_weak = 0,
pointer_equality_needed = 0, dynstr_index = 0, u = {weakdef = 0x0,
elf_hash_value = 0}, verinfo = {verdef = 0x85bcbf0, vertree = 0x85bcbf0},
vtable = 0x0}
the linker creates an indirect symbol, pthread_mutex_init
(gdb) p *hi
$30 = {root = {root = {next = 0x8739a04,
string = 0x87720bc "pthread_mutex_init", hash = 268710567},
type = bfd_link_hash_indirect, u = {undef = {next = 0x0,
abfd = 0x8772060, weak = 0x0}, def = {next = 0x0,
section = 0x8772060, value = 0}, i = {next = 0x0, link = 0x8772060,
warning = 0x0}, c = {next = 0x0, p = 0x8772060, size = 0}}},
indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist = 0x0,
plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0},
size = 0, type = 0, other = 0, ref_regular = 0, def_regular = 0,
ref_dynamic = 0, def_dynamic = 0, ref_regular_nonweak = 0,
dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0,
hidden = 0, forced_local = 0, mark = 0, non_got_ref = 0, dynamic_def = 0,
dynamic_weak = 0, pointer_equality_needed = 0, dynstr_index = 0, u = {
weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0,
vertree = 0x0}, vtable = 0x0}
(gdb) p *hi->root.u.i.link
$31 = {root = {next = 0x865fa24,
string = 0x876b230 "pthread_mutex_init@@GLIBC_2.0", hash = 329801547},
type = bfd_link_hash_defined, u = {undef = {next = 0x0, abfd = 0x85be3a4,
weak = 0x2700}, def = {next = 0x0, section = 0x85be3a4, value = 9984},
i = {next = 0x0, link = 0x85be3a4,
warning = 0x2700 }, c = {next = 0x0,
p = 0x85be3a4, size = 9984}}}
and also an indirection from the nondefault version,
[EMAIL PROTECTED] which was undefweak from libqt-mt.so.3.3.4
(gdb) p *h
$33 = {root = {next = 0x85d2380,
string = 0x85a9ea0 "[EMAIL PROTECTED]", hash = 421875337},
type = bfd_link_hash_indirect, u = {undef = {next = 0x0, abfd = 0x8772060,
weak = 0x85890e8}, def = {next = 0x0, section = 0x8772060,
value = 140021992}, i = {next = 0x0, link = 0x8772060,
warning = 0x85890e8 "\002"}, c = {next = 0x0, p = 0x8772060,
size = 140021992}}}
(gdb) p *h->u.i.link
$34 = {root = {next = 0x865fa24,
string = 0x876b230 "pthread_mutex_init@@GLIBC_2.0", hash = 329801547},
type = bfd_link_hash_defined, u = {undef = {next = 0x0, abfd = 0x85be3a4,
weak = 0x2700}, def = {next = 0x0, section = 0x85be3a4, value = 9984},
i = {next = 0x0, link = 0x85be3a4,
warning = 0x2700 }, c = {next = 0x0,
p = 0x85be3a4, size = 9984}}}
and this code:
/* If the indirect symbol has been referenced, we need to
push the reference down to the symbol we are
referencing. */
if (h->type != bfd_link_hash_new)
{
row = UNDEF_ROW;
cycle = TRUE;
[Bug gas/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-15 12:24 --- 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). -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/848] gas testsuite FAIL: macros dot
--- Additional Comments From jbeulich at novell dot com 2005-04-15 13:34 --- This is more wide-spread, other affected targets are hppa, ns32k, and vax. Slightly different reasons cause d30v, dlx, i860, and or32 to fail. For these, the testcase output expectation needs to be adjusted; I have a tentative patch to do so. There may be more, but many targets currently don't build (due to -Werror). -- What|Removed |Added CC||jbeulich at novell dot com http://sources.redhat.com/bugzilla/show_bug.cgi?id=848 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/847] New: Error: Zero-length symbol is illegal
Nick Clifton <[EMAIL PROTECTED]> 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 ""' 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 <[EMAIL PROTECTED]> > > 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 "". > * 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 ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/847] Error: Zero-length symbol is illegal
--- Additional Comments From ian at airs dot com 2005-04-15 14:56 --- Subject: Re: New: Error: Zero-length symbol is illegal Nick Clifton <[EMAIL PROTECTED]> 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 ""' 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 <[EMAIL PROTECTED]> > > 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 "". > * 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 -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/847] Error: Zero-length symbol is illegal
--- Additional Comments From jbeulich at novell dot com 2005-04-15 15:26 --- 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. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/847] Error: Zero-length symbol is illegal
--- Additional Comments From ian at airs dot com 2005-04-15 16:35 --- 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. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=847 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
