Feedback on ld circular reference resolution code?

Feedback on ld circular reference resolution code?

[Ted Lemon]

I sent in a patch a few weeks ago which adds an option to ld which
allows a library to be searched more than once, so that when object
modules in two libraries refer to each other, those references can be
correctly resolved.

I haven't seen this code appear in the tree, and I haven't gotten back
any kind of flame indicating why it might not be worth adding as it
stands.   I would appreciate it if one of these two things could occur.
If the code isn't good enough for some reason, perhaps I can modify
it so that it is good enough.   If it's just that nobody's had time to
look at it, I'd at least like to know that that's what's happening,
and maybe how I can help to make integrating the change easier.

Thanks in advance.

			       _MelloN_

Feedback on ld circular reference resolution code?

[Ian Lance Taylor]

   Date: Thu, 28 Apr 94 11:07:26 PDT
   From: Ted Lemon <mellon@ncd.com>

   I sent in a patch a few weeks ago which adds an option to ld which
   allows a library to be searched more than once, so that when object
   modules in two libraries refer to each other, those references can be
   correctly resolved.

Well, firstly, I haven't really had time to look at it.

Secondly, though, I don't really understand why it is needed.  My
first inclination when seeing a new feature is to say ``no.''  The GNU
stuff is already, IMHO, much too large and complex.  Adding features
makes it worse.  It seems to me that you can just write the library
name twice on the link line and get the same effect.  Why is it worth
adding such an option to the linker?  How many people will ever
actually use a feature which is not necessary and is only available in
the GNU linker?  When discussing a new feature, I don't think it's
enough to say ``here it is;'' it has to be a major lack to not have
it.

Despite these arguments, the FSF requires a new linker feature for
Hurd support which is somewhat similar to yours.  They need to have
some way to search a set of libraries as though they were a single
library.  It seems to me that that would solve your problem as well.
If you have good patches for that, I would certainly put them in.  In
fact, since this feature must get implemented, it seems to make your
proposed patch even less necessary.

Ian

Re: Feedback on ld circular reference resolution code?

[Richard Stallman]

      It seems to me that you can just write the library
    name twice on the link line and get the same effect.

You don't know whether twice is enough.  It depends what is in the two
libraries.  Maybe -la -lb -la -lb -la will work, for the current
version of the libraries.

Maybe for the next version of the libraries that won't be enough, and
you will have to change it to -la -lb -la -lb -la -lb -la -lb.

Feedback on ld circular reference resolution code?

[Ian Lance Taylor]

   Date: Thu, 28 Apr 94 15:06:31 -0400
   From: rms@gnu.ai.mit.edu (Richard Stallman)

	 It seems to me that you can just write the library
       name twice on the link line and get the same effect.

   You don't know whether twice is enough.  It depends what is in the two
   libraries.  Maybe -la -lb -la -lb -la will work, for the current
   version of the libraries.

   Maybe for the next version of the libraries that won't be enough, and
   you will have to change it to -la -lb -la -lb -la -lb -la -lb.

I believe you are discussing the feature you have requested, which is
different from the feature that Ted implemented.  His implementation
appears to have the effect of repeating the library name at the end of
the link line, and no more.  Maybe I misread it.

Ian

Re: Feedback on ld circular reference resolution code?

[Ted Lemon]

> I believe you are discussing the feature you have requested, which is
> different from the feature that Ted implemented.  His implementation
> appears to have the effect of repeating the library name at the end of
> the link line, and no more.  Maybe I misread it.

The feature operates as RMS described it, not as you are assuming it
operates.   Why would I go through all that effort to implement
something that could be done with a trivial command-line hack?

			       _MelloN_

Feedback on ld circular reference resolution code?

[Ian Lance Taylor]

   Date: Thu, 28 Apr 94 12:14:45 PDT
   From: Ted Lemon <mellon@ncd.com>

   The feature operates as RMS described it, not as you are assuming it
   operates.   Why would I go through all that effort to implement
   something that could be done with a trivial command-line hack?

I apologize.  I must have misunderstood what the code was doing.

Let me back up, then.

I would still prefer to see a feature more like what the FSF is
requesting.  One that would essentially treat a set of libraries as a
single library.

One problem with my revised understanding of your patches (and please
correct me if I am wrong) is that the libraries are researched after
all the input files have been seen.  This will not work if there are
any object files which come at the very end of the link, which is
generally the case for COFF and ELF.  For example, gcc on COFF or ELF
requires that the crtend.o file be linked last, after all everything
else (except a possible crtn.o) has been linked.  Do your patches
accomodate that?

Also, adding new fields to the BFD structure itself must be avoided if
at all possible.  I am constantly being beaten up about BFD memory
usage, and doing a link on a large archive can open hundreds of BFD's.
Each new four byte field in a BFD structure can lose a noticeable
amount of memory.

Ian

Re: Feedback on ld circular reference resolution code?

[Richard Stallman]

    I believe you are discussing the feature you have requested, which is
    different from the feature that Ted implemented.

I haven't see his code.  I saw only his textual description, which made
it sound like the same feature we asked for.

Re: Feedback on ld circular reference resolution code?

[Richard Stallman]

    I would still prefer to see a feature more like what the FSF is
    requesting.  One that would essentially treat a set of libraries as a
    single library.

We should have both interfaces for requesting this feature.
One is with a virtually merged library, and the other is with
command line options.

    One problem with my revised understanding of your patches (and please
    correct me if I am wrong) is that the libraries are researched after
    all the input files have been seen.  This will not work if there are
    any object files which come at the very end of the link, which is
    generally the case for COFF and ELF.

Indeed, this feature should not be limited to coming at the end of the
link.  You should be able to specify a group of jointly searched
libraries at any point.

Re: Feedback on ld circular reference resolution code?

[Ted Lemon]

> I would still prefer to see a feature more like what the FSF is
> requesting.  One that would essentially treat a set of libraries as a
> single library.

Sounds fine to me.   I haven't seen the request from the FSF, though.
Could I?

> One problem with my revised understanding of your patches (and please
> correct me if I am wrong) is that the libraries are researched after
> all the input files have been seen.

That's correct.

> For example, gcc on COFF or ELF requires that the crtend.o file be
> linked last, after all everything else (except a possible crtn.o)
> has been linked.  Do your patches accomodate that?

Nope.   I hadn't thought of that.   However, from what I've heard, if
I were to update my patches to do what rms is asking for, this would
satisfy your objection.   Although I do use ELF, I haven't had to use
crtend.o, so I wasn't aware that it was an issue.

> Also, adding new fields to the BFD structure itself must be avoided if
> at all possible.  I am constantly being beaten up about BFD memory
> usage, and doing a link on a large archive can open hundreds of BFD's.
> Each new four byte field in a BFD structure can lose a noticeable
> amount of memory.

Well, if we use your description (hundreds of BFDs), this would mean
at a maximum that we'd be using an additional 8k, since if you meant
over 2000 BFDs, you probably would have said ``thousands.''   I don't
mean to belittle the importance of conserving memory, but I have to
admit that I'm having trouble getting worked up about this.
Certainly it would be bad to add fields that serve no purpose, but I
think this is a weak argument against adding the feature we're talking
about.

In any case, if I can get a description of exactly what the FSF wants,
I'll be happy to modify my patch to provide a solution.   I could
probably make a guess from what's been alluded to in previous
messages, but I'd rather get it right the first time.

			       _MelloN_