13 Mar
2007
13 Mar
'07
11:31 a.m.
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)
13 Mar
13 Mar
11:01 p.m.
New subject: Endianess
On Tue, 13 Mar 2007 07:31:14 -0400
"Tristan Miller" <trismandev(a)gmail.com> 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
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)
14 Mar
14 Mar
9:21 a.m.
New subject: Endianess
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(a)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
10:59 p.m.
New subject: Endianess
On Wed, 14 Mar 2007 05:21:34 -0400
"Tristan Miller" <trismandev(a)gmail.com> wrote:
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.
I think the safest is for this work to be isolated in the ppc branch for now.
Trunk has had quite enough activity on its own. If we're going BE, we can
simplify the ofw interface generator that's in there too.
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?
AFAIK they have standard defaults (64k/1meg)
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?
I get the framebuffer address from ofw in a similar way to linux before the
mmu takeover. After we take over the MMU, it's just us, the CPU and anything
that lives in the physical map left. Physical writes are done by loading
the desired value and the writing it with MSR[DR]=0. Not too clever but it
gets the job done. My intention was to eventually map the FB, once mm had
been sorted out. The nice thing about using my scheme is that it'll work
even if virtually everything else is broken :-)
Thanks
~Tristan Miller
(monocasa)
On 3/13/07, art yerkes <ayerkes(a)speakeasy.net> wrote:
--
The way out is via the door. Why is it that no one will use this method? - Confucius
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
6596
days inactive
6597
days old
3 comments
2 participants
participants (2)
-
art yerkes -
Tristan Miller