Mr Taylor surely understands ld: a correction to my previous post

[root at jacob dot remcomp dot fr (root)]

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".