[llvm-commits] [patch] Trying to enable EH support in the MCJIT

[Jim Grosbach]

+1.  The remote stuff is a new thing that the old jit didn't support, but is very important to the mcjit model. While it adds some complexity, the payoff is pretty huge by giving us explicit handling for things that compile servers and cross compilation need.

Jim
On Dec 4, 2012, at 12:06 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> Hi Rafael,
> 
> The general problem I have with this patch is that MCJIT and RuntimeDyld need to be able to handle the case where the code being emitted will be run in an external process.  The way you've implemented this seems to be at odds with that goal.  In the 'remote' case, we need a way to call __register_frames in the target process and we shouldn't call it in the host process.  In any event, the frame registration should be deferred until MCJIT::finalizeObject() is called, as the emitted memory may move before then.  We have the same problems with the registerWithDebugger call, and that should also be moved out of MCJIT (which is on my list of things to do).
> 
> There is a similar difficulty with resolving external functions.  We're currently handling that by delegating function resolution to the [RuntimeDyld|JIT]MemoryManager.  I've always thought it didn't quite belong there and that instead we need a new object to handle linking issues.  Your EH support would seem to likewise make sense in such an object.
> 
> Perhaps in the short term you can add something to the RuntimeDyldMemoryManager interface to register the frames along with a note saying that it should find a new home eventually.
> 
> That brings me to my second comment, which is that I'd prefer not to have the example code use the DefaultJITMemoryManager if it's going to use MCJIT.  As you know, the plan is for the old JIT stuff to go away when it can and I'm hoping that MCJIT can be completely severed from the old JIT interfaces even sooner.  The RuntimeDyldMemoryManager doesn't currently support setPoisonMemory, but it probably should.  Otherwise, is there any reason that SectionMemoryManager wouldn't work for this ExceptionDemo code?
> 
> -Andy
> 
> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] 
> Sent: Saturday, December 01, 2012 7:48 PM
> To: llvm-commits
> Cc: Kaylor, Andrew
> Subject: Re: [patch] Trying to enable EH support in the MCJIT
> 
> An updated version is attached. I added the getTailObjectData virtual function and moved all the ELF specific bits to ELF files.
> 
> I started trying to add MachO support, but found a bug in MachOObjectFile::getSectionName (see llvm-commits message).
> 
> Cheers,
> Rafael