<div dir="rtl"><div class="gmail_extra"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">There may be two problems with __register_frame usage. However based on </div><div dir="ltr"><br></div><div dir="ltr">

<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html</a><br>
</div><div dir="ltr"><br></div><div dir="ltr">I think the existing code is correct for OS-X but likely buggy for Linux and Windows systems.<br></div><div dir="ltr"><br></div><div dir="ltr">Your crash is on OS-X, right?</div>

<div dir="ltr"><br></div>
<div dir="ltr">Anyhow, the first problem is very easy to fix.  On Linux and Windows (at least) __register_frame should be called once and not called on every FDE as in processFDE in RTDyldMemoryManager,cpp does.</div><div dir="ltr">


<br></div><div dir="ltr">So RTDyldMemoryManager::registerEHFrames was modified to:</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><font face="courier new, monospace">void RTDyldMemoryManager::registerEHFrames(uint8_t *Addr,</font></div>


<div dir="ltr"><font face="courier new, monospace">                                           uint64_t LoadAddr,</font></div><div dir="ltr"><font face="courier new, monospace">                                           size_t Size) {</font></div>


<div dir="ltr"><font face="courier new, monospace">  __register_frame(Addr);</font></div><div dir="ltr"><font face="courier new, monospace">}</font></div><div dir="ltr"><br></div></div><div dir="ltr">On Windows 7 / MingW (gcc) this completely solved the problems I had with erratic exception behaviour.</div>


<div dir="ltr"><br></div><div dir="ltr">The second issue is a bit more complicated. With executable files, the linker combines .eh frames with four zero bytes from crtend to marking .eh_frame section end. As Rafael writes, this can't be done in codegen since it's a linker function done when all .eh_frames are combined.</div>


<div dir="ltr"><br></div><div dir="ltr">The dynamic linker must perform the same function, else __register_frame(.eh_frame) might continue processing after .eh_frame, depending if there were four zero bytes following it - or not - by chance. </div>


<div dir="ltr"><br></div><div dir="ltr">However this again isn't likely to be your source of problem, as __registerframe on OS-X processes one FDE at the time and the calling function  processFDE() in RTDyldMemoryManager.cpp does know the size of eh_frame so it will not overrun the frame.</div>


<div dir="ltr"><br>The solution would be to allocate a larger buffer, copy .eh_frame into it with four zero bytes appended. This buffer needs to live as long as long it's registered in the runtime library.<br></div><div dir="ltr">


<br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div></div>