X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Message-ID:	<48CAFDD9.641C423A@dessent.net>
Date:	Fri, 12 Sep 2008 16:40:09 -0700
From:	Brian Dessent <brian AT dessent DOT net>
X-Mailer:	Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
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>
X-IsSubscribed:	yes
Reply-To:	cygwin AT cygwin DOT com
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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

Dave Korn wrote:

>   If they were instead resolved to some kind of thunk that could do a lookup
> at runtime for non-weak versions of the same symbol, we'd be golden.  Well,
> we'd need to make sure the non-weak versions were all declspecced dllexport
> somehow, but that would do it for us.

Well we already have this problem with the Cygwin DLL and standard
malloc().  It's solved in
lib/_cygwin_crt0_common.cc:_cygwin_crt0_common().  This code gets
statically linked into every executable, which means when it takes the
address of malloc and free that address will bind to the user's
overrided function if present, otherwise it will import it from the
DLL.  I think we can extend this for operator new and delete.

The only issue is the addresses are stored in an internal Cygwin data
structure (struct per_process) which will not be accessible from within
libstdc++.  You could add helper functions that retrieve them, but that
seems like additional overhead.  You could also just store them in
variables that are exported by the DLL.  Then you'd just need something
in libstdc++ that wraps all calls to new/delete through the addresses
imported from those variables.  Or, how about this: you could just have
the Cygwin DLL export the wrapper functions as themselves, i.e. with the
proper mangled names.  Then building libstdc++ as a DLL would always
bind new/delete to those wrappers with no extra modification to the
libstdc++ sources.

Brian

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

- Raw text -