<div dir="rtl"><div dir="ltr">Hi Anton,</div><div dir="ltr"><br></div><div dir="ltr">On Windows, MingW, libgcc arrives pre-compiled as shared (DLL) and a static library. I'm not sure if the ld linker could help when starting from a compiled binary DLL.</div>

<div dir="ltr">In any case, instead of hacking around libgcc, completely replacing it with libcxxabi/Unwind + compiler-rt (thanks Jean!) seems to be the better alternative.</div><div dir="ltr"><br></div><div dir="ltr">Yaron</div>

<div dir="ltr"><br></div><div dir="ltr"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/11/2 Anton Korobeynikov <span dir="ltr"><<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>></span></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Yes, it's nice when the OS does the work.<br>
><br>
> With MingW, I see a problem using our unwind library.<br>
> __EH_FRAME_BEGIN__ is a local symbol with no external visibility<br>
> outside the libgcc DLL. There is no API exposing it either.<br>
> Only code compiled inside libgcc can access it.<br>
</div>In fact, no. We can (with linker support, surely), put all the EH info<br>
into the dedicated section in the PE file. And do pretty similar<br>
things, but walking the sections of PE file.<br>
<div class="im"><br>
> The right solution would be to have a full replacement to libgcc based on<br>
> our<br>
> unwind code and use it instead. In addition to unwinding library, libgcc<br>
> also<br>
> supplies conversion and arithmetic functions so we'll need alternative<br>
> versions<br>
> of these too.<br>
</div><a href="http://compiler-rt.llvm.org/" target="_blank">http://compiler-rt.llvm.org/</a> ? :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
With best regards, Anton Korobeynikov<br>
Faculty of Mathematics and Mechanics, Saint Petersburg State University<br>
</font></span></blockquote></div><br></div></div>