[ros-dev] Endianess

[Tristan Miller]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20070314/6db28040/attachment.html