[LLVMdev] A weird, reproducable problem with MCJIT

[Christian Schafmeister]

Yaron,

Did you find a way around the problem?

It looks like the problem comes before processFDE because by the time it
gets to processFDE the eh_frame data is already corrupted.

Does ELF and MachO share the same eh_frame format?

I am developing this code in parallel on an Ubuntu Linux system but I
haven't tried to run it on there for a couple of weeks.   I'll bring it
up to date and try my test case on it and we'll see what happens.

Best,

.Chris.



Yaron Keren <yaron.keren at gmail.com> writes:

> Hi,
>
> I had similar problems with EH in ELF in
> RTDyldMemoryManager::registerEHFrames() calling __register_frame().
>
> I'm not sure these problems are related to this problem since your
> crash happens in  RuntimeDyldMachO::registerEHFrames() in its own
> processFDE (there are two functions named processFDE(), one in
> RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp)
>  before RTDyldMemoryManager::registerEHFrames() and __register_frame()
> are called.
>
> It would seem that even if  RTDyldMemoryManager::registerEHFrames()
> and __register_frame() got problematic input (as with the ELF dyn.
> linker) it should not cause a crash in the calling code but either a
> malfunction of exceptions or crash in
> RTDyldMemoryManager::registerEHFrames() / __register_frame(). A crash
> like the one you see should be related
> to RuntimeDyldMachO::registerEHFrames() inputs only.
>
> Yaron
>
>
>
> 2013/10/14 Kaylor, Andrew <andrew.kaylor at intel.com>
>
>     Hi Christian,
>     
>     Thanks for sharing this.
>     
>     Yaron Keren has been investigating some problems in the EH frame
>     registration code recently, and I think this may be related.  It
>     at least sounds similar to the type of variations in behavior
>     based on code size that Yaron was seeing.
>     
>     -Andy
>