[LLVMdev] A weird, reproducable problem with MCJIT

[Yaron Keren]

Hi,

There may be two problems with __register_frame usage. However based on

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html

I think the existing code is correct for OS-X but likely buggy for Linux
and Windows systems.

Your crash is on OS-X, right?

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.

So RTDyldMemoryManager::registerEHFrames was modified to:

void RTDyldMemoryManager::registerEHFrames(uint8_t *Addr,
                                           uint64_t LoadAddr,
                                           size_t Size) {
  __register_frame(Addr);
}

On Windows 7 / MingW (gcc) this completely solved the problems I had with
erratic exception behaviour.

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.

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.

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.

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.

Yaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131014/2d983b51/attachment.html>