Re: Your change to ldlang.c

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Ian" == Ian Lance Taylor <ian@zembu.com> writes:

    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.

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

    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?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com