[PATCH] Build libgcc_s on Windows

[Dave Korn]

Danny Smith wrote on 21 August 2008 04:45:

>> Why are the references to __register_frame_info in crtbegin weak in the
>> first place?  Shouldn't it always be able to find these symbols in
>> libgcc, whether dynamic or not?  It's not obvious to me what case there
>> would be where this symbol would not be available.
> 
> If there is no need for unwind info  then it is unnecessary to pull in
> unwind-dw2-fde.o  from static libgcc.a.  Mingw users have in past
> complained when unwind-dw2-fde.o was always pulled in, saying that it
> was unwanted bloat for small apps.
> 
> Danny

  I agree with this; we want the exception handling machinery to be optional.

  I found it necessary to apply a patch like the attached before it would
actually work correctly in the case where you're *not* pulling in the EH
machinery - otherwise it ends up jumping to NULL because some optimiser
somewhere 'knows' that an unresolved weak makes the program invalid and
doesn't consider the possibility after seeing

   if (h)
     register_frame_fn = (void (*) (const void *, struct object *))
 			GetProcAddress (h, "__register_frame_info");
-  else 
-    register_frame_fn = __register_frame_info;

that register_frame_fn could still be zero.  Danny, what did you mean by:

Danny Smith wrote on 19 August 2008 04:11:

> While your at it you may as well clean up the use of
> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

... ?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crtbegin.diff
Type: application/octet-stream
Size: 4525 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20080827/f31d806f/attachment.obj>