Re: Nobody in the world understands Gnu's 'ld'.

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

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

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

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

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

[Fergus Henderson]

Jacob Navia wrote:
> 
> 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!!!

Here's one possible reason (there may be others).

Different object file formats formats have different sets of capabilities.
In general, conversion from one format to another format may not be
able to preserve all the information.  If the linker required all
inputs to have the same format, then you might have to use a lossy
conversion, and that might prevent successful linking.

One possible solution to this problem would be to invent a new object
file format whose capabilities were a superset of the capabilities of
all other object file formats.  Then, you could ensure that the
conversion to this object file format was non-lossy.  However, this
approach would be more complex than the BFD approach, not less complex.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Ian Lance Taylor wrote:
> 
> Let's not get carried away here.  I understand the linker perfectly
> well, and so do a number of other people.
[...]
> In fact, BFD works quite well.

Yes, I agree.  Let's not get carried away.

However, let's not forget the point either: the GNU ld code
is poorly structured and poorly documented.

> Mind you, I'm not going to defend the way that BFD is written.
> [...] I've tried to clean up some of the more egregious
> problems.  Unfortunately, the cost of rewriting BFD is high.

Right.  So what is the solution?  Well, in the case of BFD, perhaps the
damage is already done -- the cost would have been a lot cheaper if it
was done right in the first place.  However, even now, Cygnus should
seriously consider spending the money to improve the quality of their
existing source code, because it may be a *good investment*.

Regardless of what happens with BFD, Cygnus ought to ensure that
whatever code they write is well documented and properly structured.
This will result in products that are easier to maintain, easier
to extend, and as a result in the long term the products will be better.

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

Documentation should not be an after-thought.  If Cygnus thinks that
it can economize by not bothering with documentation or not bothering
to write properly structured code, then they are wrong -- it may result
in some short-term gains, but in the long run it will cost them a lot.
It is much more difficult (and expensive) for someone to come along
afterwards and write documentation than for the person doing the
original work to write the documentation properly in the first place.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Joel Dinolt]

Fergus Henderson wrote:

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.
> This will result in products that are easier to maintain, easier
> to extend, and as a result in the long term the products will be better.
<cut> 
I don't know if all this stuff about "Cygnus should do this, Cygnus
should do that..." is accurate...I thought GNU ld was part of the
standart GNU package, and that the ld with cyg-win32 was just a port
win32 port of the standard GNU ld. If this is the case, it's not
really Cygnus that should be "making sure it is well documented
and properly structured."  I would assume that the structure has been
an evolution over many years(like emacs or rcs or cvs) and has been
tinkered with by many people.  And as far as documentation, it might
be easiest to start at the GNU Home Page, since it is the cyg-win32 
ld is based on the standard GNU ld...of course, if the ld is 
a custom linker that cygnus wrote, it's another matter...but
free software is free software, and you have the source, as
cryptic as it may be.  Isn't 70% of programming getting frustrated
by having to read someone elses oddly structured code to figure out
what it does?  I could be speaking from a somewhat tainted perspective
here, as I'm a video game programmer doing a port, and I do windows
programming "for fun"....

Regards,
Joel Dinolt,
jdinolt@pacbell.net
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Joel Dinolt wrote:
> 
> I thought GNU ld was part of the
> standart GNU package, and that the ld with cyg-win32 was just a port
> win32 port of the standard GNU ld. If this is the case, it's not
> really Cygnus that should be "making sure it is well documented
> and properly structured."

`ld' is part of the GNU binutils package, but Cygnus is (I believe)
the central maintainer of that package, just as Linus is the central
maintainer of the Linux kernel, Richard Kenner of the FSF is the
central maintainer of gcc, etc.

> I would assume that the structure has been
> an evolution over many years(like emacs or rcs or cvs) and has been
> tinkered with by many people.

Of course, but central maintainer who is responsible for merging in
all the different patches, issuing new releases, etc., should also
be responsible for maintaining the quality of the software.

> And as far as documentation, it might
> be easiest to start at the GNU Home Page, since it is the cyg-win32 
> ld is based on the standard GNU ld...

I was talking mainly about source documentation, not user documentation.
The user documentation for `ld' is actually quite good.

> but free software is free software, and you have the source, as
> cryptic as it may be.

Uh, no offence, but this sounds to me like a cop-out: are you
suggesting that because it is free software, it doesn't matter if the
quality is poor?

(Thankfully the people at Cygnus who have responded to this thread
_don't_ have that attitude.)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Pedro A. Aranda Gutiirrez]

Fergus Henderson wrote:
> 
> Ian Lance Taylor wrote:
> >
> > Let's not get carried away here.  I understand the linker perfectly
> > well, and so do a number of other people.
> [...]
> > In fact, BFD works quite well.
> [...]
> However, let's not forget the point either: the GNU ld code
> is poorly structured and poorly documented.

Yes, I'd not be as mild as Fergus. I went through the same sorrows as
Jacob Navia when trying to understand the DLLTOOL source. It was 
'somehow' documented and completely unstructured, ergo not
understandable.

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.

This is something I learnt years ago in University and even my
personal 'quick-hacks' follow this philosophy. It really pays off.

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

Contributions sold afterwards by Cygnus. Forgive me, but if my
work is going to produce benefits, they should be for me and not
for someone else. I'm no DOn Quijote.

Ergo => all this commercial licensing stuff of Cygnus has somehow
rarified the atmosphere of FSF'ish software (that's at least my 
feeling and my VERY personal opinion)

-- 

     +--------------------------------------------------------+
     |  ####   Pedro Andres Aranda Gutierrez                  |
     |  ####                                                  |
     |  ####   Telefonica I+D;  Network Interconnection Div.  |
     |  ====   C./ Emilio Vargas, 6    E-28043 Madrid, Spain  |
     |  ====   e-mail : paag@tid.es                           |
     |  ====   Tlf 34-1-337 47 02      FAX 34-1-337 45 02     |
     +--------------------------------------------------------+
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   Date: Wed, 26 Mar 1997 15:13:49 +0100
   From: "Pedro A. Aranda Guti\irrez" <paag@tid.es>

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

   Contributions sold afterwards by Cygnus. Forgive me, but if my
   work is going to produce benefits, they should be for me and not
   for someone else. I'm no DOn Quijote.

   Ergo => all this commercial licensing stuff of Cygnus has somehow
   rarified the atmosphere of FSF'ish software (that's at least my 
   feeling and my VERY personal opinion)

Don't get confused.  BFD, gas, ld, the binutils, are all under the GPL
and always have been.  Any contributions you or anybody chooses to
make will be made under the GPL, will require a copyright assignment
to the Free Software Foundation, and will be included in future
binutils net releases for anybody to use.

The commercial licensing stuff applies only to the gnu win32 library
itself, which is copyrighted by Cygnus.  It does not apply to the
binutils.

On another topic, to quote you: ``if my work is going to produce
benefits, they should be for me and not for someone else. I'm no DOn
Quijote.''  I'm sorry you feel that way.  If you are using the GNU
binutils, or any FSF software, or indeed the GPL version of gnu-win32
itself, then you are benefitting from the work of people who are
rather less selfish than you seem to be.

I've been working in free software for several years now, starting
some years before I joined Cygnus.  I would certainly say ``if my work
is going to produce benefits, they should be for me.''  I don't work
out of altruism.  However, I would never say that the benefits should
not be for someone else as well.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Commercial Licensing

[David Essex]

Ian Lance Taylor <ian@cygnus.com> wrote:

>BFD, gas, ld, the binutils, are all under the GPL
>and always have been.  Any contributions you or anybody chooses to
>make will be made under the GPL, will require a copyright assignment
>to the Free Software Foundation, and will be included in future
>binutils net releases for anybody to use.
>
>The commercial licensing stuff applies only to the gnu win32 library
>itself, which is copyrighted by Cygnus.  It does not apply to the
>binutils.
Commercial licensing ?
The cygnus gnu-win32 web page says that this is free software.
If win32 library is part of gnu why do you need a commercial license ?
Could some one expand on this ? 

David


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

David Essex wrote:
> 
> Ian Lance Taylor <ian@cygnus.com> wrote:
> 
> >BFD, gas, ld, the binutils, are all under the GPL
> >and always have been.  Any contributions you or anybody chooses to
> >make will be made under the GPL, will require a copyright assignment
> >to the Free Software Foundation, and will be included in future
> >binutils net releases for anybody to use.
> >
> >The commercial licensing stuff applies only to the gnu win32 library
> >itself, which is copyrighted by Cygnus.  It does not apply to the
> >binutils.
> Commercial licensing ?
> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ?


In addition to the GPL, Cygnus offers cygwin.dll under a restricted
license to commercial clients who wish to use it without sharing their
own sources.  As the owner, Cygnus has every legal right to do this.
Whether it is consistent with the spirit of the GPL is another matter.
There was a long, heated debate on the mailing list after Cygnus
posted a press release announcing their intentions; no sense in
repeating it.

Note that many libraries, such as glibc, are released under the LGPL,
not the GPL, implicitly allowing commercial users to do what commercial
users of cygwin must pay Cygnus for a license to do.  Cygnus
intentionally used the GPL rather than the LGPL for just this reason.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Geoffrey Noer]

> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ? 

I just expanded the explanation for this a bit on the main WWW page.
Hopefully it will cut down on the amount of mail on this list that
pertains to this subject.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   From: Fergus Henderson <fjh@cs.mu.oz.au>
   Date: Wed, 26 Mar 1997 18:17:04 +1100 (EST)

   > Mind you, I'm not going to defend the way that BFD is written.
   > [...] I've tried to clean up some of the more egregious
   > problems.  Unfortunately, the cost of rewriting BFD is high.

   Right.  So what is the solution?  Well, in the case of BFD, perhaps the
   damage is already done -- the cost would have been a lot cheaper if it
   was done right in the first place.  However, even now, Cygnus should
   seriously consider spending the money to improve the quality of their
   existing source code, because it may be a *good investment*.

   Regardless of what happens with BFD, Cygnus ought to ensure that
   whatever code they write is well documented and properly structured.
   This will result in products that are easier to maintain, easier
   to extend, and as a result in the long term the products will be better.

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

   Documentation should not be an after-thought.  If Cygnus thinks that
   it can economize by not bothering with documentation or not bothering
   to write properly structured code, then they are wrong -- it may result
   in some short-term gains, but in the long run it will cost them a lot.
   It is much more difficult (and expensive) for someone to come along
   afterwards and write documentation than for the person doing the
   original work to write the documentation properly in the first place.

I'll note that I agree with all of this.  In particular, we've
certainly discussed whether rewriting BFD is a good investment or
not.  There is no obvious right answer.

People may think that Cygnus is a large software company with hundreds
of programmers designing products.  This is not the case.  It was even
less the case when BFD and the linker were written.  At that time,
Cygnus was a handful of programmers working with free software and
struggling to succeed by meeting customer demands very quickly.  It's
easy to second guess the decisions made at that time.  In fact,
though, you weren't there, and neither was I.  Programming decisions
are not made in an academic environment.  They are made in the real
world, under the pressure of time and money.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Nobody in the world understands Gnu's 'ld'.

[dahms]

Hi Jeff, you wrote:

:  I wrote some tools to convert any BFD supported object format into
: 'resources' for the USR Pilot PDA device
[snip]
Probably not really relevant for this thread, but anyway I'm curious
what this device is, please...


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Nobody in the world understands Gnu's 'ld'.

[Sean McNeil]

I may take a stab at fixing the offset problem.  But since this feature
would only be used for a limited time here, I won't waste more than a few
hours on it.  If you really need this feature, don't hold your breath for a
patch from me.

Try the following:

*** gas/config/obj-coff.c~      Wed Dec 31 16:01:33 1969
--- gas/config/obj-coff.c       Sun Mar 23 14:20:52 1997
***************
*** 3176,3183 ****
--- 3176,3185 ----
      {
        long size;

+ #ifndef TE_PE
        segment_info[i].scnhdr.s_paddr = addr;
        segment_info[i].scnhdr.s_vaddr = addr;
+ #endif

        if (segment_info[i].scnhdr.s_name[0])
        {

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Stan Shebs]

root@jacob.remcomp.fr (root) 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.

Steve moved on a year ago, and hasn't done anything with gnu-win32
since then.

> There is only ONE person in the world that understands that code
> and he is called Steve Chamberlain. If Cygnus doesn't have
> him any more, users of gnu-win32 will have to live with a flawed linker
> for the rest of their lives.

Not true; we have several people that understand how the linker works.
Even Stan the manager has some knowledge of this stuff... :-) If the
linker has a problem that remains unfixed, it's because there is
neither a Cygnus business reason, nor a volunteer willing and able to
do the job.  It's very telling that with well over a thousand people
on this mailing list, including many who are using gnu-win32 in their
jobs, not one deems the problems sufficiently important to a) solve
themselves, or b) pay Cygnus to solve for them.

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

Linker scripts are extremely important for embedded programming; you
need the script to be able to do memory layouts and special section
handling.  Many of Cygnus' customers write their own scripts, some
of them quite sophisticated.

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

If you think that, then you don't yet understand BFD.  BFD provides a
common API to multiple formats, but is not itself a format.  Although
I agree that the implementation of BFD is atrocious, the concept is a
big winner, and has enabled all kinds of advances, including for
instance the ability to bootstrap things like gnu-win32 from any other
host.

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

People at Cygnus and elsewhere are adding BFD backends all the time;
just check the ChangeLogs.  It's not fiendishly difficult, but it
does require a certain amount of ability and experience.

> I think that anybody using 'ld' is living very dangerously...

Well, ld is used to link many, perhaps even most, of the Internet
programs that passed your epistle from there to here.  Going by the
code in some of those programs though, I doubt that ld is the major
risk factor! :-)

							Stan

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Jim Balter]

Stan Shebs wrote:

> It's very telling that with well over a thousand people
> on this mailing list, including many who are using gnu-win32 in their
> jobs, not one deems the problems sufficiently important to a) solve
> themselves

You don't know that.  I've fixed a lot of bugs in your stuff
that I'm not yet prepared to share.  One of the things that stops me
is that I do not want someone else to incorporate my work into a
product that is sold under a restricted license, certainly not if I
have to sign away my rights to it.

> or b) pay Cygnus to solve for them.

I have repeatedly pointed out to people that if they want any sort of
response from you guys, they will probably need to buy a license.



As far as the comments about "no one undertands GNU ld",
what can one say other than that ignorance abounds?

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[David Dyck]

On Tue, 25 Mar 1997, Jim Balter wrote:

> Stan Shebs wrote:
> 
> I've fixed a lot of bugs in your stuff
> that I'm not yet prepared to share.  One of the things that stops me
> is that I do not want someone else to incorporate my work into a
> product that is sold under a restricted license, certainly not if I
> have to sign away my rights to it.

Is there something else that keeps you from sharing your work?

You could always _post_ your bug report and the bug fix patch,
  or do you think that no one else will encounter the bugs you have 
  found and fixed?


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Hans Zuidam]

> root@jacob.remcomp.fr (root) writes:
[ a lot of ramblings about the GNU linker, typical
 for someone who hasn't seen that much ]

> Stan Shebs wrote:
> ... It's not fiendishly difficult, but it
True, only fiendishly tedious... :-)

A sad thing about the current GNU code is that it starts to show
it's age.  Look at the average gdb debugger interface: cut and
paste programming and lots of comments about the writer being
uncertain if [s]he's doing the right thing.  Then when you write
your own interface, you are forced to do the same, the only other
option would be to rewrite major parts.

Another sad thing is that it works so damn well!  If you just close
your eyes and go ahead with implementing those changes needed for
your particular environment, you always end up with something that
works reliable.  That is when you remember the old proverb: if it
ain't broke, don't fix it.

Regards,

				Hans

-- 
H. Zuidam                        E-Mail: hans@brandinnovators.com
Brand Innovators B.V.            P-Mail: P.O. Box 1377
de Pinckart 54                   5602 BJ Eindhoven, The Netherlands
5674 CC Nuenen                   Tel. +31 40 2631134, Fax. +31 40 2831138
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Marcus G. Daniels]

>>>>> "HZ" == Hans Zuidam <hans@brandinnovators.com> writes:

HZ> A sad thing about the current GNU code is that it starts to show
HZ> it's age.  Look at the average gdb debugger interface: cut and
HZ> paste programming and lots of comments about the writer being
HZ> uncertain if [s]he's doing the right thing. 

GNU pr

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Marcus G. Daniels]

>>>>> "HZ" == Hans Zuidam <hans@brandinnovators.com> writes:

HZ> A sad thing about the current GNU code is that it starts to show
HZ> it's age.  Look at the average gdb debugger interface: cut and
HZ> paste programming and lots of comments about the writer being
HZ> uncertain if [s]he's doing the right thing. 

Anyone who has read the diffs of daily snapshots or looked through
ChangeLog files knows this isn't the whole story.  Development is a
constant process of apply/generalize/simplify.  You are just pointing
to the first part and ignoring the others.  Comments like that are
honest and useful.  As for the linker, keep in mind that the
information which is available for targeting certain platforms can
often be of a low quality; there can be significant uncertainty about
what it *ought* to do.  

I'm seen many examples of Mr. Taylor and others at Cygnus rewriting
code.  What you report is the exception not the rule, especially when
it comes to the complex high-maintenance stuff.


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Nobody in the world understands Gnu's 'ld'.

[D. Jeff Dionne]

[stuff chopped]
> 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.
> 

If this is indeed the case, this is IMHO unfortunate.  I wonder if
the departure has anything to do with the license nonsense Cygnus is
engaged in of late...  But on to 'ld' specific stuff...

[chop]
> 
> 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: 

Oh rubbish.  The fact that 'ld' (or more correctly, BFD) supports _many_
file formats is absolutely _useful_.  On 68k I've used just about 
everything BFD has to offer, and would still be messing around with
little bits of custom code if it did'nt!

> an incredible complexity
> that (to me) seems completely unwarranted. 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.

I must admit if I could find some docs on it, I'd be happy.  I could
always go read the yacc code, but I get on with it reasonably well so
far without.  This again is a _great_ thing, very useful.  Ppl (like
me) _do_ use it.

> 
> 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, 

Not format.  Set of 'back ends' to any and all file formats with a consistant 
interface.  Works quite well, very useful.

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

Nonsense.  If you only need to understand the interface that BFD provides,
and in most cases not even the file format you're working with.  If you
just had a bunch of random functions that mess about with your file
format, you'd need to understand those and you've gained absolutly nothing.
Next file format, next set of nonsense.  BFD solves that.  It's not 
fundamentally BFD's fault if the Win32 implementation it has is broken...

[chop]
> 
> 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!!!

Actually, IMHO the construction _is_ nice, but the lack of accessable 
documentation is a hinderance to ppl using this stuff.  I wrote some
tools to convert any BFD supported object format into 'resources' for
the USR Pilot PDA device and had to rely on code from something else,
and a look at the headers to figure out what functions in libbfd.a to
call :-(  I would prefer to just build this stuff into BFD, but...
If the documentation does exist, it would be a great help if it could
be made more accessable (perhaps stick a pointer to it somewhere we
can find it easily)?

[chop]
> I think that anybody using 'ld' is living very dangerously...

'ld' is not perfect, and BFD seems to have a few inconsistant things in
the way it handles even (nornal) COFF files, and the situation is
frustrated by not being able to locate documenetation.  That having
been said, 'ld' (and BFD and the rest of binutils) are things I can't
live without when doing something more than just... ho hum... build
me an executable for a standard supported target.  When doing a new target
(like for instance the USR Pilot, or an embedded system), the flexibility
'ld' gives with it's little 'linker' language means I can build an 'ld'
_OUT OF THE BOX_ and produce _TARGET SPECIFIC_ output without modification
to it's code.  This is a plus.  I don't need to mess about with funny
conversion programs (they are taking about this over on the mc68332
list today) to make any kind of file format I want, or 5 of them, thanks
to BFD.  We need to get those docs accessable, though.

Jeff.

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

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Jim Balter]

Colin Peters wrote:
> 
> A. Phillip Smith[SMTP:asmith@www.aeinc.com] wrote:
> [snip]
> >of fact that the mere INCLUSION of a particular Win32 call caused the
> >GUI portion of a program to apparently fail (silent death). Note that
> >the code was NEVER invoked, as I stated, so usage errors are not at
> >issue.
> >
> >This is further complicted on Windows NT by the fact that unless you strip
> >the executable, the binary will not run. Hence you have no VCC++ debugging OR
> >gdb debugging capability. Here's another simple program in it's entirety.
> >Compile it per the gcc line. It works fine. Now uncomment the statement
> >containing the GetFullPathName call, and rebuild. If you get something
> >other than the "silent death" behaviour, please share it. This seems like
> >a bug to me, unless there's some other link options of which I'm unaware...
> [snip - Code example]
> 
> It doesn't seem to be a code generation problem, or at least not an easy
> one to reproduce. I must point out that I compiled with Mingw32 and not
> the normal Cygnus libraries, so there is some chance (small though it may
> be) that the Mingw32 environment removes or influences this bug in some
> strange way. Another possibility is that it is an NT thing, since I did
> the compile on 95 (where you don't have to strip to get a working exec
> either, so debugging is possible with GDB). Anyway the point is that it
> works, both ways, no problem. (The compile line under Mingw32 is slightly
> different, but essentially comes down to the same arguments for cc1 and
> ld).
> 
> Are you using a completely vanilla version of GNU-Win32 or have you made
> changes to things (like the startup code for example)? Could you send me
> a copy of your silently failing binary?
> 
> Colin (If it is a compiler bug lets find it and fix it) Peters.
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT? Is there a difference between the -s link option and using
>     strip after linking?

Under NT 4.0, the program dies just by virtue of *referencing*
GetFullPathName, without calling it (as APS said).  The following
is enough to cause the access violation:

  #include <windows.h>

  void (*xxx)() = GetFullPathName;

  int STDCALL
  WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
  {
        return 0;
  }

I've tracked this down, and have determined that it dies with a SIGSEGV
which doesn't get printed anywhere because cygwin.dll prints it to
STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
at the very least writing it to the strace output if that is a file, and
a
MessageBox would be nice.  A useful option would be to not set the
exception handler, so that the windows debugger would get it.
APS' complaint that silent exit is a bug is quite valid, but it isn't
something to be surprised about from alpha software like cygwin.dll.

The point at which it dies is the at the very beggining of main()
from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
jump instruction that goes
through an indirect pointer that appears to contain the wrong
address, since it is the address of some code.  The jump uses the
content of that code as the "location" to go to, and so it
dies.  Perhaps to someone who knows about Windows dll's and jump tables,
the problem here might be obvious, but I know nothing of those things.
But it sure looks like a serious screwup by ld.

If someone wants to pursue this who can run the MS debugger under NT
4.0,
the easiest way is to build a version of cygwin.dll with the
init_exceptions call in dcrt0.cc commented out (or ignored based
upon an environment variable, so you can control it dynamically).


A word about the comments from drs@inxpress.net:

>>... I merely stated a point
>> of fact that the mere INCLUSION of a particular Win32 call caused the
>> GUI portion of a program to apparently fail (silent death). Note that
>> the code was NEVER invoked, as I stated, so usage errors are not at
>> issue.
>
> I would have to see this to believe it.

He gave an example.  His WinMain never gets called,
let alone the GetFullPathName call that triggers the problem.

>> Compile it per the gcc line. It works fine. Now uncomment the statement
>> containing the GetFullPathName call, and rebuild. If you get something
>> other than the "silent death" behaviour, please share it. This seems like
>> a bug to me, unless there's some other link options of which I'm unaware...
>
> The code you posted failed to work as expected, Phillip, because you 
> are not using it correctly. What you posted works exactly as advertized
> by the SDK. The API puts the path and the file-name together. That's it.
> It does not verify the presence of the file name. It is not a "search" 
> api at all. Granted, this is a pretty stupid behaviour, but then I'm not 
> an MS apologist. The API in question works correctly and compiles
> correctly
> under gnu-win32. You simply don't know how to use it.

Your arrogance is unwarranted and unearned.
His usage was perfectly reasonable, even if his comment that refers to
"search" is misleading.  In any case, his use or misuse is irrelevant
when the complaint was that the code died silently.  There is nothing
in any SDK that would indicate that MessageBoxes should never show up,
with not even a Dr. Watson popup.  The fact that the code works as
advertised on *your* system is irrelevant when the behavior of the code
on *APS's* system was described ("silent death") and is incorrect.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Nobody in the world understands Gnu's 'ld'.

[root]

Jim wrote:
> 
>   void (*xxx)() = GetFullPathName;
> 
>   int STDCALL
>   WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
>   {
>         return 0;
>   }
> 
> I've tracked this down, and have determined that it dies with a SIGSEGV
> which doesn't get printed anywhere because cygwin.dll prints it to
> STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
> at the very least writing it to the strace output if that is a file, and
> a
[snip]
> 
> The point at which it dies is the at the very beggining of main()
> from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
> jump instruction that goes
> through an indirect pointer that appears to contain the wrong
> address, since it is the address of some code.  The jump uses the
> content of that code as the "location" to go to, and so it
> dies.  Perhaps to someone who knows about Windows dll's and jump tables,
> the problem here might be obvious, but I know nothing of those things.
> But it sure looks like a serious screwup by ld.

A dll call under windows (NT or 95) is just a jump through a
table of pointers to functions. This table (called 'import table')
is built by the linker. 

The linker builds this table by using an 'import library'. That
library contains several small pieces of code and special
sections that, when combined together with some pieces of
code in the startup (the famous .idata$3 section) will build
that import table in the executable.
This is an extremely complex and error prone process, that costed
me months of horrible work when I wrote the linker for my
system. I was VERY happy when it was over...

Gnu's linker: A NIGHTMARE!
-------------------------

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.

Before writing my linker, I studied gnu's linker code with the
naive assumption that I could use it. After spending weeks and weeks
trying to understand it, I gave up and wrote mine.

There is only ONE person in the world that understands that code
and he is called Steve Chamberlain. If Cygnus doesn't have
him any more, users of gnu-win32 will have to live with a flawed linker
for the rest of their lives.

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

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.

And then you have the macro-sickness... You read:
	a = foobar(b->field);

Well, where is foobar? Nowhere. It is a macro that will be expanded
into an index into a table using b. Mmmm. This table is
actually an table of tables. MMMMMMMMMMM. OK let's go on.
In that table of tables you have a field that is a table of
functions. GOD! WHATS THIS!!! But let's go on. That table
of functions is indexed by that b->field to jump into ???
IT DEPENDS OF THE RUNTIME CONDITIONS. Of course! You can at
the linker command line change the output format remember?
You can link your windows object files to give a SUN OS
executable isn't that FUN???

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!!!

Not surprisingly, Cygnus is stuck with a linker that nobody 
in the world understands... except Steve of course. But I think
*even he* has problems to know what the hell is going on in there...

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

I think that anybody using 'ld' is living very dangerously...

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

Re: Nobody in the world understands Gnu's 'ld'.

[Tim Iverson]

Actually, quite a few people understand GNU's ld very well indeed (I do,
for one, and I suspect the folks at Cygnus understand it much better).  And
yes, I not only use the scripting language, I rely on it quite heavily.  It
is indispensable when preparing images for an embedded system.

I've also linked disparate object formats with GNU-ld, and for the formats
it supports, it usually works quite well.  Of course, I usually also
manually inspect the output for the first couple of images ... ;-)

The only problem I've come across with the NT/95 b17.1 GNU ld was the
screwed up offsets when linking OMF and GNU-pe-i386 objects with a
commercial linker.  I had assumed this was a Phar-Lap problem or just an
incompatible image problem -- I'm a little out of date wrt. MS; didn't know
MS' "PE" really was COFF+MS (thanks for info win32-folks ;-).  There are
other reports of the same problem with the MSVC linker, though.  So, I now
suspect a minor bug in the GNU implementation of pe-i386.

BTW, before you start throwing around all these assumptions about what 'we'
need in a linker, consider that I would indeed prefer support for a.out,
ELF, and other Unix object formats over support for linking MSVC objects or
libraries.  That would be a feature I would use.  Linking with MSVC objects
would be a feature I would not use.  GNU-ld is one of the major attractions
to using the GNU toolset.  The implementation has it's drawbacks, but overall
it is a rather large step forward in the linking game.

The whole GNU concept is driven by people who need a feature bad enough to
actually implement it, and generous enough to share the results of their
efforts.  Whine all you want, but be aware that mostly it just irritates
the folks that spend time writing useful code.

I may take a stab at fixing the offset problem.  But since this feature
would only be used for a limited time here, I won't waste more than a few
hours on it.  If you really need this feature, don't hold your breath for a
patch from me.

Damn, anyone got a pair of pliers?  I seem to have this trolling hook
stuck in my mouth ... ;->


- Tim Iverson
  iverson@cisco.com

\f
+----------------
| From: root@jacob.remcomp.fr (root)
| Subject: Nobody in the world understands Gnu's 'ld'.
| To: jqb@netcom.com (Jim Balter)
| Date: Tue, 25 Mar 1997 08:23:33 +0100 (MET)
| Cc: gnu-win32@cygnus.com
| 
| Gnu's linker: A NIGHTMARE!
| -------------------------
| 
[very long anti-GNU-ld diatribe, heavily paraphrased: I can't comprehend
 GNU ld, therefore I gave up and wrote my own linker.  No one ever uses
 half the features of GNU ld anyway.  All we really need is MSVC object
 and library support.]
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Jacob Navia wrote:
> 
> Gnu's linker: A NIGHTMARE!
> -------------------------

... followed by a lot of nonsense and one good point.

> Since several months people here report that Cygnus's linker is flawed.
[...]
> Before writing my linker, I studied gnu's linker code with the
> naive assumption that I could use it. After spending weeks and weeks
> trying to understand it, I gave up and wrote mine.
[...]
> 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.

As others have noted, the features that you complain about _are_
highly desirable and people do use them.

> And then you have the macro-sickness... You read:
> 	a = foobar(b->field);
> 
> Well, where is foobar? Nowhere. It is a macro that will be expanded
> into an index into a table using b. Mmmm. This table is
> actually an table of tables. MMMMMMMMMMM. OK let's go on.
> In that table of tables you have a field that is a table of
> functions. GOD! WHATS THIS!!! But let's go on. That table
> of functions is indexed by that b->field to jump into ???
> IT DEPENDS OF THE RUNTIME CONDITIONS.

This sort of programming -- emulating C++ virtual functions in C -- is
a pretty common idiom (e.g. the Linux kernel uses similar techniques).
I didn't find it difficult to understand.

> And to crown this beatiful construction there is NO DOCUMENTATION
> whatsoever about anything I have told you in this message.

This is Jacob Navia's one good point.

It does seem to me that the authors of GNU ld
don't really have much idea about software engineering.
For example, there are some functions in there that are
thousands of lines long.  Yes, that's right, 5000 lines
of code, all of it a single C function.

Documentation and proper structuring of code should NOT be
after-thoughts.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".