Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!isncr!ra From: ra@intsys.no (Robert Andersson) Newsgroups: comp.sys.ncr Subject: Re: ld on Tower is different from all other SYSV ld's. Message-ID: <1990Nov4.220326.4626@intsys.no> Date: 4 Nov 90 22:03:26 GMT References: <1990Oct31.122907.2448@intsys.no> <1990Nov1.215030.2530@cc.Columbia.NCR.COM> Organization: International Systems A/S, Oslo, Norway. Lines: 34 haug@cc.Columbia.NCR.COM writes: >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. I was actually not aware that NCR got all this from Motorola. Now I know. >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. Someone must have put this special casing of 68xxx processors in there for some reason. If this was it, it was a bad one. The result of the final link will have a different magic number, and thus users trying to be to clever would be detected by ld. Besides, architectures other than the 68xxx manage to get along just fine without this "fix". Anyway, I have actually managed to get around it now. gdb now runs just fine on the Tower, and is one hell of an improvement over sdb. It took some hacking though, hacking which shouldn't have been necessary IMHO. -- Robert Andersson Voice +47 2 371055 International Systems A/S ra@intsys.no Fax +47 2 356448 P.O. Box 3356 ...!{uunet,mcsun,nuug}!intsys.no!ra 0405 Oslo 4, NORWAY