ra@intsys.no (Robert Andersson) (10/31/90)
This problem shows up while I am porting the GNU debugger, gdb, to
the Tower. It causes me all sorts of problems in doing so.
I'm running release 3.00.01 on a 4x0/6x0 machine if that matters.
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?
Is there *any* way to get around the problem? I'm open to suggestions
like:
Use some special undocumented option.
Use some sort of ifile directive.
Binary patch the ld executable.
Regards, Robert.
--
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, NORWAYhaug@cc.Columbia.NCR.COM (11/02/90)
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.
ra@intsys.no (Robert Andersson) (11/05/90)
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