Nobody in the world understands Gnu's 'ld'.
Ian Lance Taylor
ian@cygnus.com
Tue Mar 25 12:55:00 GMT 1997
In gnu-win32 root@jacob.remcomp.fr writes:
>Since several months people here report that Cygnus's linker is flawed.
>I think that it is just plain that Cygnus doesn't have the
>know-how to repair it, since Steve Chamberlain, the guy that
>wrote most of it, hasn't posted anything here since ages and
>he was very active before.
Let's not get carried away here. I understand the linker perfectly
well, and so do a number of other people.
It's true that Steve Chamberlain left Cygnus a while ago.
If you look at the ChangeLog files, you can see who has been working
on the linker and other parts of BFD. You'll see that although Steve
wrote most of the original code several years ago, he hasn't been
heavily involved with BFD or the linker for quite some time.
>Just to give you an idea, ld is supposed to link an object file
>from sun's unix format with some code from windows 95 and with
>some code of hp Unix. Of course this is ridiculous and it will never
>work, but this is how 'ld' is designed: an incredible complexity
>that (to me) seems completely unwarranted.
It's true that it is rare for people to link together different object
file formats. However, you have missed the actual reasons for the
complexity.
The first reason is that 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. This may not be too useful for native
programmers, but it is useful for embedded systems programmers.
The second reason is that a single linker binary can serve as the
linker for different targets. The Linux people use this, for example:
the binary binutils distribution for Linux is built to support all the
various Linux targets in a single binary.
>It has a full blown LANGUAGE
>(with lex+yacc parser/lexer!) that is supposed to recognize linker
>commands. Obviously nobody ever uses it, but to understand
>what the linker is doing you have to go through yet another layer
>of complexity.
In fact, many people use the linker script language. I can't imagine
why you think that nobody uses it. Moreover, this is hardly a unique
or even unusual feature of the GNU linker: most linkers have a
scripting language, and the one used by the GNU linker is based on the
one used by the SVR3 linker.
>Then you have the 'BFD' format, that is supposed to be an universal
>binary format designed by GNU that will abstract the binary format
>of all machines in the western world into ONE format. Obviously
>it doesn't work, but then you have not only to understand what
>binary format you have in windows (what is difficult enough) but
>you have to understand BFD too.
In fact, BFD works quite well. I don't know why you think that it
doesn't work.
It's not quite correct to describe BFD as abtracting all binary
formats into one format. What it actually does is provide a library
interface which may be used to examine and generate an object file in
any format.
Mind you, I'm not going to defend the way that BFD is written. There
is definitely a very steep learning curve before being able to program
using BFD. I've tried to clean up some of the more egregious
problems. Unfortunately, the cost of rewriting BFD is high.
>And to crown this beatiful construction there is NO DOCUMENTATION
>whatsoever about anything I have told you in this message. I inferred
>this from reading THE C CODE!!!
I'd love to have some documentation if you care to write some and
contribute it. This is, after all, free software. It improves by
contributions.
>That is why this linker can't even recognize MSVC object code
>format and use the MSVC .LIBs. Because nobody in the world
>is able to modify it. Of course we do not need compatibility
>with SUN or HP Unix under Windows 95. We would need MSVC
>compatibility. But to do that we would have to find somebody
>that understands 'ld'...
Well, all you need to do is add support for the object code format to
BFD. I'm sorry you think that is impossible. In fact, BFD supports a
number of object file formats already, including a.out, COFF, ELF,
IEEE-695, XCOFF, SOM, etc. Adding another one is really not all that
difficult if you know what you are doing.
I'm always willing to answer specific questions about BFD and the
linker. I'm not willing to give a tutorial on how to program it,
because I simply don't have the time.
I suppose I should add that my personal interest in adding MSVC object
support is nil. I do work at Cygnus, but I don't work on gnu-win32,
and I have no idea whether Cygnus has any plans to do anything in this
area.
Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
More information about the Cygwin
mailing list