This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]
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.