This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]