<div dir="rtl"><div dir="ltr">Reviewing the code, the problem is not with processes. Without any Dwarf support from Windows, MingW (Windows) libgcc load the EH frame by itself. First it:</div><div dir="ltr"><br></div><div dir="ltr">
<div dir="ltr"><div dir="ltr"><font face="courier new, monospace">/* Stick a label at the beginning of the frame unwind info so we can</font></div><div dir="ltr"><font face="courier new, monospace"> register/deregister it with the exception handling library code. */</font></div>
<div dir="ltr"><font face="courier new, monospace">static EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]<br></font></div><div dir="ltr"><font face="courier new, monospace"> __attribute__((used, section(EH_FRAME_SECTION_NAME), aligned(4)))</font></div>
<div dir="ltr"><font face="courier new, monospace"> = { };</font></div><div dir="ltr"><br></div></div><div>then the linker merges all EH frames together with the above being first so that in runtime __EH_FRAME_BEGIN__ points to the start of the EH frame.</div>
<div><br></div><div>Finally at runtime the CRT init code registers the frame:</div><div><br></div><div><div><font face="courier new, monospace"> register_frame_fn (__EH_FRAME_BEGIN__, &obj);</font></div></div><div>
<br></div><div>The root of our problem is that __EH_FRAME_BEGIN__ is registered with the MingW (gcc) exception runtime library but not with our libunwind so it does not know how to unwind its own functions. That's why the IP is out of range the FDE tables.</div>
<div><br></div><div>So, findUnwindSections needs to know about __EH_FRAME_BEGIN__ . I'll try this.</div><div><br>Yaron<br></div><div><br></div></div></div><div class="gmail_extra"><div dir="ltr"><br><br><div class="gmail_quote">
2013/10/31 Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">
<div dir="rtl"><div dir="ltr">I see. It is different than the gcc runtime libgcc. </div><div dir="ltr"><br></div><div dir="ltr">libgcc always uses the set of FDE which was registered by __register_frame. This data is private to every process since unwind runs in user space as part of the process.</div>
<div dir="ltr"><br></div><div dir="ltr">Here, the OS first locates which set of FDE is relevant. </div><div dir="ltr">Does this mean that in OS-X unwind runs in system space and holds FDE data for all processes?</div><span class="HOEnZb"><font color="#888888"><div dir="ltr">
<br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div><div dir="ltr"><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/10/31 Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Oct 30, 2013, at 3:22 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="rtl"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">You are exactly correct, LocalAddressSpace::findUnwindSections does nothing #if !APPLE so the output value is random.</div>
<div dir="ltr"><br></div>
<div dir="ltr">LocalAddressSpace::findOtherFDE and LocalAddressSpace::findFunctionName also currently do nothing. Are these also required for regular exceptions?</div></div></blockquote></div><div>No. </div><div><br></div>
<div>findOtherFDE() is only need if the OS has an alternate way to locate FDEs such as those for JITed code.</div><div><br></div><div>findFunctionNam() is used in debug builds to print out the name of functions as the unwinding happens.</div>
<span><font color="#888888"><div><br></div><div>-Nick</div></font></span><div><div><div><br></div><br><blockquote type="cite"><div dir="rtl"><div dir="ltr"><br></div></div><div class="gmail_extra">
<div class="gmail_quote"><div dir="ltr">2013/10/31 Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div style="word-wrap:break-word"><div>Yaron,</div><div><br></div><div>Each separately linked image (program, DLLs, etc) has its own set of FDEs (in its .eh_frame) section. The method LocalAddressSpace::findUnwindSections() needs to be updated in an OS specific way to: 1) find the image for a given pc value, and 2) find the .eh_frame section bounds for that image.</div>
<span><font color="#888888"><div><br></div><div>-Nick</div></font></span><div><div><div><br></div><br><div><div>On Oct 30, 2013, at 3:03 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:</div>
<blockquote type="cite"><div dir="rtl"><div dir="ltr">Hi Nick,</div><div dir="ltr"><br></div><div dir="ltr">I looked at the disassembly, unw_getcontext() gets the correct IP into the context and later setInfoBasedOnIPRegister gets it right into "pc". This is OK.</div>
<div dir="ltr"> </div><div dir="ltr">The trouble is, the whole address space is nowhere near the fde values. For example, </div><div dir="ltr"><br></div><div dir="ltr"><font face="courier new, monospace">p = 0x66179070 <libunwind::DwarfFDECache<libunwind::LocalAddressSpace>::_initialBuffer></font></div>
<div dir="ltr"><font face="courier new, monospace">pc = 0x6604e7d9</font></div><div dir="ltr"><font face="courier new, monospace">fde = 0x40801c0</font></div><div dir="ltr"><font face="courier new, monospace">p->ip_start = 0x4080010</font></div>
<div dir="ltr"><font face="courier new, monospace">p->ip_end = 0x408010c</font></div><div dir="ltr"><br></div><div dir="ltr">p is consistent with pc and local vars and addresses in unwind.dll (0x66YYYYYY)</div><div dir="ltr">
fde is consistent with the ip ranges and with the caller of unwind.dll (the throwing function) address space (0x40800YY)</div><div dir="ltr"><br></div><div dir="ltr">they live in different memory ranges, the fde addresses are in caller range whereas the unwind addresses are in the DLL range so when it tries to find its IP in the fde tables it can't find.</div>
<div dir="ltr"><br></div><div dir="ltr">It's as if the DLL is supposed to load in other memory range, some linker option required?</div><div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/10/29 Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On Oct 29, 2013, at 12:11 AM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> I'm trying to make libcxxabi / Unwind work on Windows / MingW 32 bit. Attached is a patch to make it compile without warnings and run without crashing.<br>
><br>
> However the functionality isn't working yet: upon exception, the IP seems to be completely out of range the FDE tables. This may be related to the memory model / compilation options???<br>
</div>Take a look at UnwindRegisterRestore.s. When an exception is thrown, unw_getcontext() is called which saves all registers and the return address into a register struct. Then the FDE info is used to step through each frame and modify the register set. At which step is the IP register out of bounds?<br>
<br>
It might be that the C files need to be compiled with -fexceptions so that they have unwind tables.<br>
<span><font color="#888888"><br>
-Nick<br>
<br>
<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div>