This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
3.0 PATCH: Fix mips-tfile to avoid Tru64 UNIX V5.1 linker warning
- To: gcc-patches at gcc dot gnu dot org
- Subject: 3.0 PATCH: Fix mips-tfile to avoid Tru64 UNIX V5.1 linker warning
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Date: Tue, 12 Jun 2001 21:55:20 +0200 (MEST)
When linking gcc 3.0 compiled object files with cc -g on Tru64 UNIX V5.1, I
noticed many linker warnings like this:
hello.o: Bad proc symbol (main), index (0) should be a valid symref or indexNil
I could trace this down as follows: if you compile a trivial hello.c with
gcc, mips-tdump gives:
There are 5 external symbols, starting at 1288
[...]
Symbol# 1: "main"
Local symbol: 0
Value: 0 String index: 5 Ifd: 0
Symbol type: Proc Storage class: Text Index: 0
but the symbol at Index 0 in the local symbol table isn't related:
There are 4 local symbols, starting at 1056
[...]
Symbol# 3: "hello.c"
First symbol: 0
Value: 0 String index: 1
Symbol type: End Storage class: Text Index: 0
This is caused by mips-tfile, which (in copy_object) copies indexNil into
the output object's file symbol table, but sets it to 0 otherwise. This
seems wrong, since 0 doesn't have any special semantics, as the linker
warning above indicates.
This warning is not normally seen when linking with gcc, since -g isn't
usually passed to ld unless explicitly done so using -Wl,-g. Nonetheless,
it would be very confusing and annoying to have tons of linker warnings
generated whenever you happen to link a gcc-created object file or library
with cc -g.
See the Tru64 UNIX V5.1 Object File and Symbol Table Format Specification:
http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V51_HTML/SUPPDOCS/OBJSPEC/NV50XXXX.HTM#nav5-15
The patch below changes this to always use indexNil here, which fixes the
linker warning.
I'll fire off bootstraps on alpha-dec-osf4.0f and alpha-dec-osf5.1 to see
if this causes any problems, but the change seems save enough on Tru64
UNIX. I don't know about MIPS ECOFF systems and couldn't find any
documention on those, and there was no hint whatsoever why this curious
setting for the symbol index was chosen.
If those bootstraps pass without regressions, ok for branch and mainline?
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE
Tue Jun 12 21:01:23 2001 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
* mips-tfile.c (copy_object): Always pass indexNil for symbol
table index.
Index: mips-tfile.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/mips-tfile.c,v
retrieving revision 1.34
diff -u -p -r1.34 mips-tfile.c
--- mips-tfile.c 2000/08/24 20:31:33 1.34
+++ mips-tfile.c 2001/06/12 19:32:34
@@ -4656,8 +4656,7 @@ copy_object __proto((void))
(st_t) eptr->asym.st,
(sc_t) eptr->asym.sc,
eptr->asym.value,
- (eptr->asym.index == indexNil
- ? (symint_t) indexNil : 0),
+ (symint_t) indexNil,
((long) ifd < orig_sym_hdr.ifdMax
? remap_file_number[ifd] : (int) ifd));
}