From mboxrd@z Thu Jan 1 00:00:00 1970 From: root@jacob.remcomp.fr (root) To: gnu-win32@cygnus.com Subject: Mr Taylor surely understands ld: a correction to my previous post Date: Tue, 25 Mar 1997 20:52:00 -0000 Message-id: References: <9703251732.AA18168@tweedledumb.cygnus.com> X-SW-Source: 1997-03/msg00420.html I sent earlier this morning a message stating that nobody understands ld. This is surely not true for Mr Taylor. I saw his comments when reading ld's code, and they were helpful. I just let myself go, expressing (for the first time I think) this feeling of frustration I got from my weeks studying that code. There are some basic rules of software engineering that we somehow take for granted. For instance, a .h file contains declarations, and a .c file contains executable code. This is not the case with 'ld'. The file 'coff.h' contains executable code that is included TWICE (yes, the same file) in the code of 'ld' with different #defines as input. This works because all the functions in that file are declared static and accessed by several indirection tables. Problem is, most debuggers get confused with this... not to speak of the poor guy *reading* that code! But it is the whole philosophy behind this that is flawed. Mr Taylor writes: > ...the linker is able to generate an object file > format which is different from the input file formats. For example, > this permits the linker to directly generate S-record output without > requiring a convertor. But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!! In my view of things, it would be much better to have an easy to understand convertor to be used by systems programmers when they need S records, than to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!! Besides, 99.9999% of the people that use 'ld' daily, are loading that code to produce S records FOR NOTHING. The linker takes more space and is more difficult to maintain! MODULARITY is a thing that got lost in this 'ld' crazyness. Do a program to do ONE THING and do that well. Do another program for another task. Do not build program upon program in the same executable. You do not have a razor inside your TV set in case you want to shave yourself when watching TV!!! The linker I wrote, went the opposite direction: It is FAST, and its size is only 66K. It understands only ONE format: windows COFF object. It will crash with any other object file. It doesn't produce S-records, but it does produce a readable MAP FILE with the information of the offset of EACH LINE in your object code. And it uses Microsoft's debug info format, so you can even debug it... :-) What are the consequences of building things like 'ld'? They are better expressed by this (anonymous) comment in the file 'reloc.c' /* This relocation routine is used by some of the backend linkers. They do not construct asymbol or arelent structures, so there is no reason for them to use bfd_perform_relocation. Also, <<<<< bfd_perform_relocation is so hacked up it is easier to write a new <<<<< function than to try to deal with it. <<<<< */ So, instead of dealing with 'bfd_perform_relocation', that should relocate object code from one object format into another (!!), people write their own routines again, since that function is beyond what a human mind can follow! The fact remains, that ld is producing bad executables since a long time. Sometimes. When the program gets big enough, or when somehow a new API call is invoked. There were people that pointed that out 2-3 months ago. A program stopped working when it reached a size threshold. I have seen no announcements of any corrections. I still remain convinced that only Steve can fix this. It is a pity that he is gone. This means that this problem will remain as it is in the foreseeable future. -- Jacob Navia Logiciels/Informatique 41 rue Maurice Ravel Tel 01 48.23.51.44 93430 Villetaneuse Fax 01 48.23.95.39 France - For help on using this list, send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".