From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: mark@codesourcery.com Cc: binutils@sourceware.cygnus.com Subject: Re: Your change to ldlang.c Date: Fri, 02 Jul 1999 07:40:00 -0000 Message-id: <19990702143928.29375.qmail@daffy.airs.com> References: <19990702024311.26848.qmail@daffy.airs.com> <19990701203004Q.mitchell@codesourcery.com> <19990702033408.27051.qmail@daffy.airs.com> <19990701231549K.mitchell@codesourcery.com> <19990701231549K.mitchell@codesourcery.com> X-SW-Source: 1999-q3/msg00018.html From: Mark Mitchell 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