This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

3.0 PATCH: Fix mips-tfile to avoid Tru64 UNIX V5.1 linker warning


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));
     }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]