27
edits
Difference between revisions of "HOWTO-Dynamic Modules"
Jump to navigation
Jump to search
m
no edit summary
(Filled out "subclassing DLObject") |
m |
||
| Line 97: | Line 97: | ||
If there is already a DLObject subclass that matches the processor for your smaller target (i.e <tt>MIPSDLObject</tt>, <tt>ARMDLObject</tt>), use it! Assuming that class is in use for another working backend with dynamic modules implemented, most everything should work correctly. The one function where one should expect problems is <code>bool DLObject::relocate(Common::SeekableReadStream* DLFile, unsigned long offset, unsigned long size, void *relSegment)</code> in that your platform may generate plugins that use relocation types as of yet unsupported by that subclass of DLObject. If this is the case, you will hopefully get a helpful message at runtime, such as "Unknown relocation type 12" or something like that. You should then look up which relocation type this number refers to in the ABI for your processor (relocation types are processor-specific), add a define for the type into elf32.h next to the other relocation types for your processor (i.e. <code>#define R_ARM_ABS32 2</code>), and then add code to handle it into the relocate function (again, the ABI for your processor and pre-existing relocation code will be your friend when trying to figure this out). | If there is already a DLObject subclass that matches the processor for your smaller target (i.e <tt>MIPSDLObject</tt>, <tt>ARMDLObject</tt>), use it! Assuming that class is in use for another working backend with dynamic modules implemented, most everything should work correctly. The one function where one should expect problems is <code>bool DLObject::relocate(Common::SeekableReadStream* DLFile, unsigned long offset, unsigned long size, void *relSegment)</code> in that your platform may generate plugins that use relocation types as of yet unsupported by that subclass of DLObject. If this is the case, you will hopefully get a helpful message at runtime, such as "Unknown relocation type 12" or something like that. You should then look up which relocation type this number refers to in the ABI for your processor (relocation types are processor-specific), add a define for the type into elf32.h next to the other relocation types for your processor (i.e. <code>#define R_ARM_ABS32 2</code>), and then add code to handle it into the relocate function (again, the ABI for your processor and pre-existing relocation code will be your friend when trying to figure this out). | ||
If there isn't already a DLObject subclass that matches the processor for your smaller target, you will have to make one that overrides <tt>relocate</tt> and <tt>relocateRels</tt>. You can look to these functions in <tt>backends/plugins/arm-loader.cpp</tt> and <tt>backends/plugins/mips-loader.cpp</tt> for a template of how to code for them. Again, the hardest part will be the code for the actual relocations. You'll want to first detect what these relocations are (you can do this using objdump on generated plugin files), then look up how they are supposed to be handled in the ABI for your processor. Since we pre-link to let ld do some of this relocation work for us, you should make builds that don't do this pre-linking with the plugins and ones that do and compare to see exactly what this work is. That way, you won't write relocation code for difficult things the linker already does for you. Careful reading and persistence will pay off at this point :-) | If there isn't already a DLObject subclass that matches the processor for your smaller target, you will have to make one that overrides <tt>relocate</tt> and <tt>relocateRels</tt>. You can look to these functions in <tt>backends/plugins/arm-loader.cpp</tt> and <tt>backends/plugins/mips-loader.cpp</tt> for a template of how to code for them. Again, the hardest part will be the code for the actual relocations. You'll want to first detect what these relocations are (you can do this using objdump on generated plugin files), then look up how they are supposed to be handled in the ABI for your processor. Since we pre-link to let ld do some of this relocation work for us, you should make builds that don't do this pre-linking with the plugins and ones that do and compare to see exactly what this work is. That way, you won't write relocation code for difficult things the linker already does for you (a lot of the time for absolute jumps, all you have to do is add the main offset of the plugin). Careful reading and persistence will pay off at this point :-) | ||