<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>Le 1 nov. 2013 à 23:11, Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="rtl"><div dir="ltr">Yes, it's nice when the OS does the work. </div><div dir="ltr"><br></div><div dir="ltr">With MingW, I see a problem using our unwind library.</div><div dir="ltr"><br></div><div dir="ltr">__EH_FRAME_BEGIN__ is a local symbol with no external visibility</div>
<div dir="ltr">outside the libgcc DLL. There is no API exposing it either.</div><div dir="ltr">Only code compiled inside libgcc can access it.</div><div dir="ltr"><br></div><div dir="ltr">One solution is to (re)place our unwind library inside gcclib</div>
<div dir="ltr">itself so our unwind gets EH frame from initialization just </div><div dir="ltr">like gcc unwind does. Another would be to add API to libgcc exposing it.</div><div dir="ltr">Both are unlikely to happen.</div>
<div dir="ltr"><br></div><div dir="ltr">The right solution would be to have a full replacement to libgcc based on our </div><div dir="ltr">unwind code and use it instead. In addition to unwinding library, libgcc also </div>
<div dir="ltr">supplies conversion and arithmetic functions so we'll need alternative versions </div><div dir="ltr">of these too.</div></div></blockquote><br><div>Isn't it what compiler-rt does ? </div><div><br></div><div><a href="http://compiler-rt.llvm.org">http://compiler-rt.llvm.org</a></div><div><br></div><br><blockquote type="cite"><div dir="rtl"><div class="gmail_extra" dir="ltr">Yaron<br><br><br><div class="gmail_quote">
<div>
2013/11/1 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="im">On Oct 30, 2013, at 9:41 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br></div><div><div class="im"><blockquote type="cite">
<div><div>I see. It is different than the gcc runtime libgcc. </div><div><br></div><div>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><br></div><div>Here, the OS first locates which set of FDE is relevant. </div><div>Does this mean that in OS-X unwind runs in system space and holds FDE data for all processes?</div></div></blockquote></div><div>On OSX, to to find the FDE for a given pc, libunwind does the equivalent of dladdr() to find the base address of the DSO (or program) containing that pc. Then it (calls a function) which walks the mach-o data structures from the base address to find the __eh_frame section. There is no up front registration (__register_frame) of each __eh_frame section, it is done lazily.</div>
<div><div class="h5"><div><br></div><div>-Nick</div><div><br></div><blockquote type="cite"><div class="gmail_extra"><br><div class="gmail_quote"><div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left: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>Hi,</div><div><br></div><div>You are exactly correct, LocalAddressSpace::findUnwindSections does nothing #if !APPLE so the output value is random.</div>
<div><br></div>
<div>LocalAddressSpace::findOtherFDE and LocalAddressSpace::findFunctionName also currently do nothing. Are these also required for regular exceptions?</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><br></div><br><blockquote type="cite"><div><br></div><div class="gmail_extra">
<div class="gmail_quote"><div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left: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><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><div>Hi Nick,</div><div><br></div><div>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> </div><div>The trouble is, the whole address space is nowhere near the fde values. For example, </div><div><br></div><div><font face="courier new, monospace">p = 0x66179070 <libunwind::DwarfFDECache<libunwind::LocalAddressSpace>::_initialBuffer></font></div>
<div><font face="courier new, monospace">pc = 0x6604e7d9</font></div><div><font face="courier new, monospace">fde = 0x40801c0</font></div><div><font face="courier new, monospace">p->ip_start = 0x4080010</font></div>
<div><font face="courier new, monospace">p->ip_end = 0x408010c</font></div><div><br></div><div>p is consistent with pc and local vars and addresses in unwind.dll (0x66YYYYYY)</div><div>
fde is consistent with the ip ranges and with the caller of unwind.dll (the throwing function) address space (0x40800YY)</div><div><br></div><div>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><br></div><div>It's as if the DLL is supposed to load in other memory range, some linker option required?</div><div><br></div><div>Yaron</div><div><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</blockquote></div><br></div>
</blockquote></div></div><br></div>
</blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div><div class="gmail_extra" dir="ltr"><br></div></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>-- Jean-Daniel</div><div><br></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>