Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!hubcap!ncrcae!cs-col!cc!haug
From: haug@cc.Columbia.NCR.COM
Newsgroups: comp.sys.ncr
Subject: Re: ld on Tower is different from all other SYSV ld's.
Message-ID: <1990Nov1.215030.2530@cc.Columbia.NCR.COM>
Date: 1 Nov 90 21:50:30 GMT
References: <1990Oct31.122907.2448@intsys.no>
Reply-To: haug@cc.Columbia.NCR.COM (Brian R. Haug)
Organization: NCR E&M Columbia (SGS Group)
Lines: 16

In article <1990Oct31.122907.2448@intsys.no> ra@intsys.no (Robert Andersson) writes:
>The bug in ld is that it does not pass the .text, .data and .bss 
>special symbols in each .o file through to the final executable.
>All other System V ld's I have tested do, and gdb depends on it.
>
>Why did NCR break this?

   NCR did not "break" this.  The code we have received from Motorola has this
portion of code ifdef'ed for 68xxx processors.  Without digging into the code
extensively, I can not explain why this is done, but I believe it is related
to the way relocations are done.  All of the relocation points are relative to
the beginning of the segment, by removing the symbols for the segments during
the final link, further links are prevented, which prevents users from doing
weird things.
   If you examine any other 68k based System V which uses Motorola's code,
I'd bet that their ld will be "broke" as well.