Charles Wilson wrote: > Or is all the worry about about unwinding a C++ only issue? (And of
As far as I can tell, it is. Note that gcc doesn't[1] emit any unwind tables for C language input, even on platforms like Linux that have been DW2 for a long time. So if you somehow managed to get yourself into a situation where you were throwing from a C++ frame and the unwinder encountered a C frame, it would call terminate() there too -- that would be undefined behavior. > But even if the unwinding differences (sjlj vs dwarf2) are NOT an issue > for C libraries, will there be incompatibilities between C client apps > that use static 3.4.5 libgcc.a and my C DLLs that use (static? shared?) > 4.3 libgcc? Aside from the EH issue, I don't think that there would be any problem. Here is a list of all the functions exported by libgcc.a and libgcc_eh.a. With the obvious exception of the EH ones and possibly the tlsemu ones, I don't see any that would carry any inherent state information such that they would get confused by one caller getting the static version and another the one from a libgcc DLL. Exception handling support: _Unwind_Backtrace _Unwind_DeleteException _Unwind_Find_FDE _Unwind_FindEnclosingFunction _Unwind_ForcedUnwind _Unwind_GetCFA _Unwind_GetDataRelBase _Unwind_GetGR _Unwind_GetIP _Unwind_GetIPInfo _Unwind_GetLanguageSpecificData _Unwind_GetRegionStart _Unwind_GetTextRelBase _Unwind_RaiseException _Unwind_Resume _Unwind_Resume_or_Rethrow _Unwind_SetGR _Unwind_SetIP __frame_state_for __gcc_personality_v0 __deregister_frame __deregister_frame_info __deregister_frame_info_bases __register_frame __register_frame_info __register_frame_info_bases __register_frame_info_table __register_frame_info_table_bases __register_frame_table Threading support: These should all map onto the respective pthreads API functions in the Cygwin DLL, so they shouldn't themselves have any state. __gnat_default_lock __gnat_default_unlock __gnat_install_locks __gthread_active_p __gthread_mutex_lock __gthread_mutex_unlock TLS support: These might carry some shared state and require -shared-libgcc. However, since this did not exist prior to 4.3 there's no backwards compatibility issue either. __emutls_get_address __emutls_register_common The rest are mostly arithmetic, which shouldn't maintain any state: DI mode (64 bit long long) arithmetic: __muldi3 __negdi2 __lshrdi3 __ashldi3 __ashrdi3 __cmpdi2 __ucmpdi2 __divdi3 __moddi3 __udivdi3 __umoddi3 __udivmoddi4 __udiv_w_sdiv Trapping arithmetic: __absvsi2 __absvdi2 __addvsi3 __addvdi3 __subvsi3 __subvdi3 __mulvsi3 __mulvdi3 __negvsi2 __negvdi2 Bit operations: __ffssi2 __ffsdi2 __clzsi2 __clzdi2 __ctzsi2 __ctzdi2 __popcountsi2 __popcountdi2 __paritysi2 __paritydi2 __bswapsi2 __bswapdi2 Float to an integer power: __powisf2 __powidf2 __powixf2 Complex mode arithmetic: __mulsc3 __muldc3 __mulxc3 __divsc3 __divdc3 __divxc3 integer<->float conversions: __fixsfdi __fixdfdi __fixxfdi __fixunssfsi __fixunsdfsi __fixunsxfsi __fixunssfdi __fixunsdfdi __fixunsxfdi __floatdisf __floatdidf __floatdixf __floatundisf __floatundidf __floatundixf Misc: _alloca __chkstk __clear_cache __enable_execute_stack __eprintf __gcc_bcmp IMHO, shared libgcc needs to be the default and all C++ libraries (and applications that link to C++ libraries) will need to be rebuilt to use it. But at the moment this is a problem because: a) gcc-4 still defaults to static libgcc, requiring -shared-libgcc flag to link with the DLL b) libgcc DLL is named just cyggcc_s.dll, but it should be versioned c) the shared gcc runtime package is currently named just "gcc4-runtime", but it should be both versioned and split into individual components, i.e. we should have libgcc0, libstdc++6, libgfortran0, and so on, however: d) shared libstdc++ doesn't exist yet because of the operator new/delete overriding issue. At the moment it looks like our best option is to leave static libstdc++ the default but have a shared option available for code that doesn't need to override operator new/delete, until (d) is fixed at which point we make shared the default. Ideally for future sanity I think we need to get away from all these static copies of the runtimes being default and make everything use DLLs, but I understand that's not practical right now. Brian [1] Well, it does if you specifically ask for it with -fexceptions or -fasynchronous-unwind-tables. But AFAIK there are no C libraries in the Cygwin distro built this way.
