X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
References: <announce.001001c91336$91e70d10$9601a8c0 AT CAM DOT ARTIMI DOT COM> <48C8FE4D DOT 1090103 AT users DOT sourceforge DOT net> <013401c9140b$22b569c0$9601a8c0 AT CAM DOT ARTIMI DOT COM> <48CA2107 DOT FE8D0CB2 AT dessent DOT net> <01cb01c914db$53d34d80$9601a8c0 AT CAM DOT ARTIMI DOT COM> <48CAFDD9 DOT 641C423A AT dessent DOT net> <48CD71CC DOT 3060704 AT users DOT sourceforge DOT net> <48CDFA0D DOT D5CC3883 AT dessent DOT net>
Subject: RE: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
Date: Mon, 15 Sep 2008 22:21:43 +0100
Message-ID: <002101c91779$0f9e8b20$9601a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <48CDFA0D.D5CC3883@dessent.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com


  I should insert a disclaimer at this point: I don't fully grok weak symbols.
What I know is what I've gathered from some googling, browsing the (very old
and I don't know in what ways outdated) copy of the gABI docs at the old
caldera site, and skimming the Codesourcery ABI pages.  

  Right, now on with throwing myself in at the deep end:

Brian Dessent wrote on 15 September 2008 07:01:

> "Yaakov (Cygwin Ports)" wrote:
> 
>> OTOH, I really would like to see a dynamic libstdc++6 for 1.7.  So my
>> question is, how far off is a real fix to binutils, and if it's not
>> around the corner, will this workaround be compatible with the binutils
>> fix when it does happen?
> 
> I haven't seen a plan outlined yet for how you'd solve this generically
> and I rather doubt it's possible without special casing or otherwise
> modifying the original code.   Like Dave said  
                [ ... ]
> add indirection
> in the form of thunks and some kind of runtime support in the startup
> code 

  Yep, that's more-or-less what I was referring to by "stunk thubbery" ;-)

  Ok: here's how PE pseudo-weak support currently works: when you build an
object containing a weakly-defined function, the assembler emits the function
renamed to some random new name, and a weak alias for the true name that
points at the random new name.

  This works when you've got a weakly defined symbol in a DLL and a
strongly-defined function in the main .exe, because the strong version
overrides the weak symbol from the dll.  So the exe calls the strong version
of the function.  Similarly, if there's a strong version in a different DLL,
that's the one the linker will resolve the .exe's reference against.

  The problem is that DLLs must be fully resolved when they are linked, and
that means that if there's nothing else for it to link against, the internal
references from the DLL to weak functions have to be resolved by the weak
alias.

  This would be the point at which to interpose a thunk.  (Actually, it could
maybe be done by a static function in the .dll.a import library, although that
would only handle the case when linking against the import library and not
when linking directly against the DLL). 

  The job of the thunk would be to do some kind of runtime lookup, and fall
back to calling the true function == the PE alias for the randomly-renamed
internal version, at that stage.  (It would be a sensible option to consider
making the thunk simply load a pointer to a symbol name, and have the bulk of
the code in the runtime library somewhere.  Shared libgcc springs to mind.)

  This thunk can do pretty much anything it needs to find a pointer to the
strong definition of the symbol (well, in fact, it just needs to find any
strong version if there's more than one, IIRC ELF doesn't guarantee which one
gets picked if you try and mix multiple strong definitions.  But in that event
it would seem to me probably best to pick one from the EXE first, ahead of any
from DLLs).  So it can walk the list of modules and check export tables and
things like that if it needs, it can even modify import and export tables if
we want, conceivably we could go so far as to re-apply relocs.

  The final piece of the puzzle is this: we need to make sure that the strong
definitions are always exported, because otherwise our runtime thunk won't be
able to find them.  Perhaps we just want to export all strongly defined
functions under an alias, that will be ignored in the normal course of events?

  Well, this is all just a vague plan in my head so far, and I imagine it'll
all fall apart when I realise the loopholes, but I haven't planned it out in
full enough detail to understand what would go wrong yet.  I guess I should
post RFDs to some combination of here, mingw, gcc and binutils lists when I've
got it a bit more concrete.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/