From: Oscar F. <of...@wa...> - 2002-07-01 01:08:52
|
Danny Smith <dan...@ya...> writes: > --- Oscar Fuentes <of...@wa...> wrote: > "Adriano dos Santos Fernandes" > <adr...@uo...> writes: > > > > > I'm create a patch to MinGW gcc 3.1 catch exceptions across EXE/DLLs > > > boundaries. > > > > I can't think of a proper inter-dll exception handling without fixing > > the "GCC 3.1 dynamic_cast fails with DLLs" bug reported by Colin > > Peters: > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=568054&group_id=2435&atid=102435 > > > > Has this problem relation with sharing objects among dlls / exes? > > > Yes, the dynamic_cast issue is critical. Adriano's solution is simple and > really does the same thing as Jason Merrill's. So it's my interpretation that Adriano's solution works even with polymorphic exceptions. > I liked Jason's because it kept the public interface clean. In any > event, the ifdef __MINGW32__ is too parochial and needs to be > extended to other targets (Cygwin, at least, Interix?, ARM with PE > object format?). That is a detail that can be cleaned up later. > Jason's suggestion also fixed problems with multiple shared libs on > other non-PE targets. Then, the path to follow is clear. What issues are pending with that patch for not being approved? > > Danny, I saw your post on the gcc ml (which, sadly, seems that didn't > > attracted too much attention, at least on-line) and know you have a > > possible solution. Do you think that Adriano's approach is useful for > > the dynamic_cast issue? His solution is really simple and > > straightfordward. > > It works. > > Other details that needs to be sorted are (1) how to prevent adding > the overhead when -fno-exceptions is given explicitly or we are > using C or Fortran or other language where no-exceptions is the > default Well, the code could check a flag and provide the old behavior. But then, mixing dll's with and without -fno-execptions would be tricky... Really, I can't understand how gcc allows mixing libraries compiled with and without support for exceptions. So far I have no experience on that issues, but it seems a can of worms to me. > (2) thread safety Put locks where needed :-) > (3) overhead when using static linkage. > I'm still not convinced that this approach is prefereable to a > libgcc_s.dll approach. Well, is one less file to distribute (less dll hell). But if libgcc_s.dll is recommended (I have no serious problem about it), it should be distributed with the MinGW distros, and then hope that people will check version before replacing files. Otherwise chaos will reign on some people's machines using more than one application built with MinGW. > What do others think? > > > Clueless, > > Clue-challenged? Only for projects that consists on more than 1,000,000 LOC of C, with hardly any documentation. GCC guys, do you really have a life? ;-}~ -- Oscar |