lists.zerezo.com
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
***BOGO*** Re: [Mingw-users] MinGW gcc 3.x, 4.x and exceptions
- Date: Sat, 03 May 2008 16:10:43 -0700
- From: Brian Dessent <brian@xxxxxxxxxxx>
- Subject: ***BOGO*** Re: [Mingw-users] MinGW gcc 3.x, 4.x and exceptions
[ PLEASE don't top-post! ]
alvaro wrote:
> Thanks again for the details.
> I increasingly realize the effort made to adapt gcc to Win32.
>
> So let me just say that this issue would be worth investigating. In the
> unlikely event that I come up with a solution I'll let you all know :-)
>
> Alvaro
>
> (naive comment: this reminds me of some C++ plugin systems that
> automatically register themselves in a single factory object existing in
> the main exe whenever a plugin DLL is loaded. The DLLs have global
> constructors that manage to, on-load, find the unique global factory
> object and register into it. I'm still not sure how)
If you want to investigate a solution that doesn't require shared
libgcc, you should look at how glibc on Linux handles it: create a
.eh_frame_hdr section and use dl_iterate_phdr() to walk all the
registered frames of the entire process at runtime rather than relying
on explicitly registering them at startup. This would require a lot of
work to port to PE:
- it would only work with Dwarf-2
- you'd have to invent something analogous to the dl_iterate_phdr()
interface used to walk ELF dynamic program headers, i.e. locate the PE
import directory of the image, traverse the list of modules therein, and
scan each module's section table to find the appropriately named one.
You would probably have to do this without the support of the
toolhlp/imghelp APIs (i.e. by accessing the PE image datastructures
directly) since those might not be universally available (I'd have to
check MSDN on that.) 9x/ME support here will give you extra headaches.
- you'd have to tweak the PE linker to generate .eh_frame_hdr
And again, this would only work with table based unwinders (i.e.
Dwarf-2) and since Dwarf-2 EH is incompatible with foreign-frame
callbacks it still wouldn't be usable by everyone. NB: one of the GSoC
projects this year lists fixing the foreign-frame issue as a bullet
point. I have no idea what the game plan there is.
Brian
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users