Re: Your change to ldlang.c

[Ian Lance Taylor <ian@zembu.com>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Thu, 01 Jul 1999 23:15:49 -0700

       Ian> It's not clear to me what SEC_LINK_ONCE semantics are in the
       Ian> case of a relocateable link.  My first reaction when I
       Ian> noticed this was actually that a relocateable link should
       Ian> keep all the sections, and that the current behaviour was
       Ian> simply a bug.

   Well, here's what it says in the code.  

	     /* When linking, duplicate sections of the same name should be
	       discarded, rather than being combined into a single section as
	       is usually done.  This is similar to how common symbols are
	       handled.  See SEC_LINK_DUPLICATES below.  */
     #define SEC_LINK_ONCE 0x100000

   I think that's pretty clear, actually.  In all cases, "duplicate
   sections of the same name should be discarded".  The
   SEC_LINK_DUPLICATES flags indicate when to complain about what, but
   don't have anything to do with the semantics.

Well, I wrote that comment in the first place.  The fact that I forgot
to think about ld -r then doesn't necessarily imply that I am wrong
now.

   I see no reason why `ld -r' should behave differently here.  In fact,
   in my Makefiles, I generally assume that `ld -r' followed by plain
   `ld' on the resulting object is roughly the same as plain `ld' on all
   the objects I used `ld -r' on in the first place; `ld -r' is just a
   way of dividing the whole link into stages.  For example, I'd be
   wicked surprised to find that `ld -r' followed by `ld' yielded a
   substantially bigger executable than plain `ld' in the first place,
   but unless I misunderstand, that's what your patch does.

I hope you misunderstand.  I agree that that would be very bad.
However, although they sections are not discarded during ld -r, they
should nevertheless be discarded during the final link.

But now that I think about it a bit more, I see what you mean.  The ld
-r will wind up merging all the sections into one, and thus you will
get a large link once section.  Actually, the original ones should be
copied into the output file unchanged.

You're right, I messed up here.  So maybe we should just revert that
patch, and then try to sort out the relocation issues, although I'm
afraid that will be fairly complicated.

Richard, I recall that you mentioned encountering a bug with ld -r and
link once sections.  Can you recall any details?

   I don't get the relocation issue, but I guess I'm just being dumb.  It
   seems like these semantics say that you can take the first input file
   which defines the section, together with the relocations it defines
   for that section, and dump everything else.  I *thought* that the
   idea was that you used SEC_LINK_ONCE for sections that should be the
   same everywhere, but that had no obvious canonical location.  For
   example, you might generate a common definition in lots of places, and
   then smash them to one definition at link-time, but it shouldn't
   matter which one you choose.

   Seems easy enough, but guess I'm missing something?

I'm not all that worried about the relocations for the input section
being discarded, although in some object file formats that will indeed
be a pain to deal with.

My concern is related to relocations in other input sections which
refer to symbols defined in the input section being discarded,
particularly if those relocations refer to local symbols in the
section being discarded.  The correct semantics would seem to be to
convert those relocations to instead refer to the link once section
which is being kept.  But actually if the relocations in question are
found in the debugging information, then I'm not even sure whether
that is right.

       Ian> Until quite recently (February 1999), .reginfo sections were
       Ian> not marked as LINK_ONCE, and they were instead handled in the
       Ian> emultempl file.  The special handling was removed by this
       Ian> patch:

   I see.  If I can't persuade you that my interpretation of
   SEC_LINK_ONCE is the One True Way :-), then may we revert this change?

Reverting that change is not a problem.  It was only done as a point
of cleanliness when it appeared that it was no longer needed.


Actually, I'm going to revert my ld -r change, at least for now.
You've convinced me that it will never do the right thing as it
stands, whereas removing it will at least sometimes do the right
thing.  We can put it back again if we figure out some different way
to solve the problems that it causes.

Ian