This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Your change to ldlang.c


On Thu, 01 Jul 1999 23:15:49 -0700, you wrote:

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

This is incorrect, it should read 

/* When linking, duplicate sections of the same name AND COMDAT SYMBOL should be discarded.

Pei ld/bfd does not implement this 
correctly, which is part of the reason
linking with vc5 implibs doesn't work. 

The rest is the sorting of the symbol table
debug or local symbols can't be comdats, ;-)
and the section sorting of .idata$X's still isn't right-(

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]