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/
