On Tue, 13 Mar 2007 07:31:14 -0400 "Tristan Miller" trismandev@gmail.com wrote:
Sorry for waiting until now to reply.
It's all good. : )
What do you think?
I think we should convert to BE, but not away from PE-COFF. There are too many differences between them, and while it would be less work in the short term to switch to ELF, in the long term, implementing all of the features of PE would be very troublesome. Not the least concern is that information such as import data and file headers aren't even mapped into a process's address space with ELF. As I understand it, when you get an IHANDLE to a linked in DLL it's just a pointer to the mapped in PE file header. I'm sure there are programs that require this on a source level to run (which, for quite some time will be the only thing that affects us on the PowerPC side of things).
That being said, a proper pe-powerpcbe target in gcc should then be the first priority. Binutils already more or less properly creates pe-powercbe files (with what I assume are your patches on the wiki, and a little monkeying to make sure that the MZ header and PE signature are always written as little-endian regardless of the target architecture). What kind of issues had you had on the EABI side of things, and what was your plan in more detail for emulating the features of PE in ELF?
Also how much progress had you made in the port up to now?
~Tristan Miller (monocasa)
The port to this point can load ntoskrnl and hal and use the OFw framebuffer to display text. Freeldr has been perverted to use openfirmware to allocate memory and access the disk, but uses its own implementation of fat32 to load files. We allocate a new PTEG area, fill it with a mapping of freeldr and the kernel area and reset SDR1 just before jumping to kernel land. I haven't yet written the code that either communicates our new page arrangement in the existing page table format or hacks what I do store for ntoskrnl's use.
The method used to write to the display is effective but slow. It could be improved.
ABI issues have been a significant sticking point at points, mainly due to the mismatch between relocation types in the ELF we're generating to be linked and the ultimate result PE. Admittedly I hadn't considered BE PE-COFF because I had mostly given up on reactivating COFF powerpc in binutils. I'd like to know what target you're using to produce pe-powerpcbe. My experience has been that the out of date portions of the coff infrastructure in binutils, combined with all the code for dead variants of coff-powerpc makes generating sensible coff-powerpc output from ld hard.
As to your question about how I'd emulate PE-coff features in elf, for dynamic linking I'd follow the example of mcore in dlltool, for resources I'd leave it as a specially named section and for the PE header, I'd make space for it at link time and have the loader construct it based on the elf info. We'd only be missing irreplaceable information like subsystem id and memory use (stack commit/reserve etc), which we could bury in a well named section with some implementation specific type. The main thing we'd have to look out for is that once tranformed, the resulting image won't be relocatable, so the loader would have to find the right aperture and use elf relocation to place everything.