plugins linking on DS

I worked through some build errors, switched my plugin.ld to use a modified version of the correct linker script and added a number of PLUGIN_LD_FLAGS (including "-mno-crt0 $(DEVKITPRO)/devkitARM/arm-eabi/lib/ds_arm9_crt0.o"), and plugins started linking. I had some trouble with plugin.ld syntax errors, but figured it out (I was doing things in SECTIONS like "{ contents } >region =fill :phdr" when it needed to be "{ contents } >region :phdr =fill"). Using objdump on the plugins, it seems most only have one relocation type to worry about (R_ARM_ABS32), but the cine and cruise engines also use R_ARM_THM_CALL and R_ARM_TARGET1. I'll be working on completing dsloader.cpp (including the ARM-specific relocations) now, my first milestone being getting one of the engines that uses just R_ARM_ABS32 working.

DS Update

Work on the DS dynamic module loader is progressing. In the tail end of last week, I put the basic loader code in for the DS and modified the default arm-eabi linker script to make a plugin linker for the DS. This week I found (in a .spec file included in one of the makefiles for the DS) that the DS port doesn't use the default arm-eabi linker so I'll have to modify the one it does use (ds_arm9.ld) instead. At the opening of this week, I took some time to try to understand the Makefiles for the DS (it's a bit more complicated than the other ports I've worked with) and then started modifying them to use dynamic modules. I had a bit of trouble getting make to attempt to link the plugins, but after correcting some dependencies, linking of plugins is attempted (though not completed successfully, which hopefully will change once I switch to a modified version of ds_arm9.ld for plugin linking). I'll post again once the plugins are successfully linking.

:-)

Tony

This week has not been the most productive thus far (though it's only just begun). I've been trying to get engine plugins building for the ds (using the custom "plugin.ld" linker script) so I can begin work on the ARM-specific relocations needed for the DS, but the way I've modified the DS makefiles, engine plugins don't build. (I currently get things like "warning: overriding commands for target 'plugins/scumm.plg'"). I'll be contacting Niel to better understand the DS make system shortly.

New Schedule up on Wiki

Check it out :-)

http://wiki.scummvm.org/index.php/User:Toneman

Restructuring

So the way the plugin loader/linker code currently works (on PS2, psp, Dreamcast) is this:

• We build a main ELF with an absolute position in memory.
• We use a custom ld linker script to link together relocatable plugins. Since the main ELF has absolute addresses, some of the more complicated jumps (like those from plugin code back to the main ELF) can be resolved during this pre-linking without the need for us to write explicit loader code for them.
• Our loader code shifts the location of a plugin in memory and adjusts relocations within the plugin.

Doing things this way (with a non-relocatable main executable and a custom ld linker script for plugins) saves us much of the more extensive and complicated work (such as maintaining a Global Offset Table).

Over the past couple of days, I've come to understand (though I'm not 100% sure) that the Wiz is unlike most "smaller targets" in that its launcher requires Position-Independent-Code. This poses quite a big problem seeing as the way we're doing things depends on the main executable having absolute addresses that the ld script can use. To implement the custom ELF loader/linker on the Wiz, then, will likely be quite an extensive task.

Since (in my proposal) I intended the Wiz to be a testbed for a more crucial target (the DS), I've talked with my mentor about moving on to other work towards supporting the DS and ditching the Wiz (at least, for now).

A good first step in this respect would be starting work on changing the plugin system to support only loading one plugin at a time. Some discussion has gone on as to how to achieve this and I've posted my current (under construction :-)) plans for it on my wiki at http://wiki.scummvm.org/index.php/User:Toneman. I'll be discussing things further with my mentor and posting schedule changes there as well (I'm not absolutely sure about whether Wiz work will continue), but for today I'm going to start looking into the DS port (possibly writing a custom linker for it and seeing what ARM relocation types I need to worry about for it).

objdump-ing

So I was trying to figure out which relocation types I really need to worry about when it comes to the GP2x-Wiz today. After making a number of tweaks to the incomplete loader to get it to compile, I compiled and linked (with my modified ARM linker script) the game engines into plugins. I tried using "objdump" on these plugin files to figure out which relocation types were worth my time, but it kept returning all types as "unknown". After a bit of research, I discovered another program "readelf" that successfully dumped relocation types. I noticed, however, that when I do use "objdump -R" which dumps a dynamic relocation table, I get output for both the main "scummvm.wiz" file and the plugin files. This leads me to believe that the binaries may be PIC, but since the version of objdump I'm using doesn't seem to support ARM (as mentioned before, it couldn't detect the relocation types), the reason it's outputting a dynamic relocation table could be because it's misreading the files, not because the files really are PIC. My goal for this weekend, then, is to become more certain about the nature of the generated files, and then to code for the relocations I may need to worry about, which are listed below (the names of some of these relocations also has me worried about PIC code):

• R_ARM_GLOB_DAT
• R_ARM_JUMP_SLOT
• R_ARM_COPY
• R_ARM_PLT32
• R_ARM_PC24 
• R_ARM_BASE_PREL
• R_ARM_GOT_BREL
• R_ARM_PC24
• R_ARM_ABS32

PS2 GP-relative section success!

As of yesterday, the PS2 port would fail to compile with Dynamic Modules turned on unless I put nothing in the GP-relative section by adding a "-G0" flag to the Defines in the Makefile. Last night (after a discussion with Yotam) I made modifications to the linker scripts used when compiling with Dynamic Modules that got rid of these errors. In the linker script for the main engine, I had an extra zero appended to a hex value specifying an offset from the GP register. Fixing this typo (along with rearranging things in plugin.ld so that the .bss section was no longer assigned to the shorts segment, but rather to the plugin segment) seemed to eliminate the problem I was having with "relocation truncated to fit errors".