gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]

[Charles Wilson]

Brian Dessent wrote:
> 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.

Okay, thanks.

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

Ack. But that'd be true on *nix, too.

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

[snip]

> 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

Hmm. But, if some existing package -- even a C-only one -- is rebuilt
with TLS support enabled (I don't know of any, I'm just speculating
here) -- then the new version will require all clients to also link
using -shared-libgcc.  So, if any maintainer makes this choice for
package X-with-TLS, that'll require a version bump.

Or, we could just assert gcc-4.3 + -shared-libgcc should be the default
for on-going cygwin-1.7-specific work, which would require all shared
libraries to get version bumped anyway.

'Course, any package (re)compiled on cygwin-1.5 using gcc-3.4.5 would
link against the cygwin-1.5 cygfoo-A.dll at compile time, and when/if
mirrored to release-2 would bind at runtime to...the cygfoo-A.dll from
release-2.

But that's exactly the behavior we expect and want. cygfoo-A.dll is "the
backwards compatible" runtime. Any new non-compatible one will exist in
release-2 only, and will be cygfoo-B.dll.

> The rest are mostly arithmetic, which shouldn't maintain any state:

Ack.

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

Eventually, sure.

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

Well, if we continue -- at present -- with static libstdc++, then would
we need to continue -- at present -- with static libgcc even for C
libraries?  For example:

cygncurses-N.dll : if this C library is compiled using -shared-libgcc

then

cygncurses++-N.dll : this C++ library can't be linked (right?) It's C++,
but depends on cygncurses-N.dll. From what I understand, you have to
have static libgcc and static libstdc++, or shared libgcc and shared
libstdc++, you can't mix them. And because you can't link against
cygncurses-N.dll (which was linked against the shared libgcc) without
specifying -shared-libgcc when linking your client...boom.

Or, am I wrong on that (I'd love to wrong about that) -- if so, then you
CAN do what would effectively be -shared-libgcc -static-libstdc++?

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

Understood.

Pending answers above, I'm leaning towards one of the following two
scenarios for my packages on 1.7.  I agree with Yaakov that now would be
a good time to transition to 4.3 [*] provided the birth pains
aren't...well, like birth pains.

[*] although the soon-to-be-released 4.4 looks really juicy. Sigh. One
thing at a time.

SCENARIO 1) rebuild all using gcc-4.3, using the default static libgcc
and static libstdc++ runtimes.   C libraries will not get version bumped
(unless they need it for another reason).  C++ libraries will get
version bumped.

Given the assurances above, it appears that clients of the
non-version-bumped libraries won't have any issues.

Later, once the issues with shared libstdc++ and new/delete, packaging
of the runtimes, versioning of the shared runtime, etc etc, are
resolved, again rebuild all using gcc-4.3 with -shared-gcc and
-shared-libstdc++ (or wait for the gcc-4.3 release with that behavior
turned on by default), and version bump everything again.

At this point, clients will probably have issues -- but that's okay,
everything is being version bumped.

SCENARIO 2) rebuild all using gcc-4.3, using the -shared-libgcc but
static libstdc++ runtimes.   C libraries will get version bumped
(because clients need to link using -shared-libgcc).  C++ libraries get
version bumped too, because of the 3.4.5->4.3 ABI changes.

Clients will probably have issues -- but that's okay, because everything
is being version bumped.

Later, once all the issues are adressed, rebuild the c++ libraries again
with -shared-libstdc++ (or the new shared default behavior of the
updated gcc-4.3). Version bump the C++ libraries again.  However, if one
of the "issues" is the versioning of the libgcc shared library, then the
C libraries will ALSO have to be rebuilt again -- but they may (or may
not) have to be version bumped again at that time.  They probably will.
 Clients from scenario 2/phase 1 expect the "old" cyggcc_s.dll -- which
was fine with cygncurses-N.dll which also used cyggcc_s.dll.  However,
this new cygncurses-N.dll depends on cyggcc_s-2.dll so now the client
will pick up two different runtime support libraries: cyggcc_s.dll
directly, and cyggcc_s-2.dll via cygncurses-N.dll. That's bad.  So, even
the C libraries will need the second version bump, for scenario 2/phase 2.

Gven all these version bumps...clients will need to be rebuilt (with the
new -shared-libgcc -shared-libstdc++ flags, or the new defaults) to use
the new DLLs. That's a lot of rebuilding.


#1 is has the possibility of being less work overall -- but probably
not; both scenario 1 and 2 will likely end up looking like "rebuild
everything twice" and "version bump everything at least once, maybe
twice".  I'd still prefer #2 because it gets us to shared-libgcc sooner
(phase 1, rather than phase 2), assuming you can mix shared-libgcc and
static-libstdc++.

--
Chuck