[llvm-commits] Add to RuntimeDyld support different object formats

[Jim Grosbach]

Hi Danil,

This looks reasonable to me. A few minor tweaks and we're set:

1. "MachODyldImpl" should probably just be "MachORuntimeDyld" or "RuntimeDyldMachO". The "Impl" suffix is an artifact of the internal vs. external aspects of the existing class, which isn't a distinction the derived classes need to make.
2. Since loadObject() is lazilly creating the runtime linker, it should probably also store off the object file type of the first loaded object and validate that subsequent objects are of the same type before trying to pass them into the linker.
3. Please scrub your changes for trailing whitespace before checking in.

A brief brain-dump of some things I've been thinking about but may not be readily apparent from the code as it currently exists:

As you continue, please keep an eye out for things we can do to share more logic between the different runtime linkers. For example, I'm hoping we can share logic for determining whether all symbols have been resolved, for managing multiple object files, for mapping symbols to target addresses, etc..

When performing relocations, keep in mind that the address that should be relocated for the symbol is not necessarily the same as the address either in the object file where it's loaded or the address allocated by the JITMemoryManager. Consider the case where the compiler is a server process which copies the code (and data) into a client process' address space (perhaps on a remote target). The relocations will need to reflect where the code and data live when it runs, not where it was compiled.

The JITMemoryManager doesn't currently have the flexibility to completely handle all of the above. For example, there's no clean way to link back from the object module to the source IR constructs for the current JITMM interfaces, so we do by-name lookups to get a mapping. For things that don't have linker-visible names (constant strings, constant pool entries, etc.), this breaks down. We'll need to do some refactoring to get that stuff to play nicely together.

Thanks for working on this!

-Jim

On Jul 1, 2011, at 12:55 AM, Danil Malyshev wrote:

> Hello everyone,
>  
> Please find attached the patch for review.
> This patch re-factors the RuntimeDyldImpl to support multiple formats as following:
>  
> 	• All MachO-specific code has been moved to a new MachODyldImpl class which derives from RuntimeDyldImpl.
> 	• Changed RuntimeDyldImpl class to keep only code common for all formats.
> 	• Changed RuntimeDyld::loadObject() to figure out the given object format and instantiate a specific implementation (for now only MachO is supported, but I’ll add implementation for ELF in the coming patches).
>  
> How does it look?
>  
>  
> Regards,
> Danil
>  
> <RuntimeDyld_different_object_formats-01.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits