Ok, sounds good. (I could have sworn that the idata - edata were being created when I would objcopy -F pei-powerpc , but thats what I get for coding at four in the morning I suppose. : P). Yeah, with the lack of any correct tools at all, I think that we should (at least for the time being) move to ELF like you said. What code repository have you been working out of, the powerpc branch in svn? I've been modifying some of the OF code to make it BE and cleaning it up a bit.
And once I create something appreciable how does one go about getting write access, and how would it work? Would I work out of my own branch, or out of trunk?
Also, a few more quick questions. Do you what sets the memory commit/reserve values? Are heuristics in the compiler applied, or are they just set by a linker flag? I don't have that much experience with MSVC... Also, without setting callbacks, or mapping OFw into your PTEG, how are you able to use the OF framebuffer to display text? Are you directly writing to the framebuffer or using the OF client interface?
Thanks
~Tristan Miller
(monocasa)
On 3/13/07, art yerkes <ayerkes@speakeasy.net> wrote:
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.
--
The way out is via the door. Why is it that no one will use this method? - Confucius