[CDG5] Building OF Client Interface Programs

Max Poliakovski maximumspatium at googlemail.com
Thu Oct 25 08:03:04 AWST 2018


Am Do., 25. Okt. 2018 um 01:45 Uhr schrieb Daniel B-J <
danielbj314 at verizon.net>:

> Hello Everyone,
>
> I am having a bit of a problem with building Client Interface Programs.
> XCOFF files (the only overlap between what PPCLink can make and what Open
> Firmware can parse) are not relocated by Open Firmware. I have to specify
> the address ahead of time. Even worse, Open Firmware insists on placing
> them at the physical address they specify, in addition to the virtual
> address specified in XCOFF sections.
>
> Additionally, I want the program I am making to not overlap with the
> Trampoline, so address ranges 0x00100000-0x0019967 and
> 0x00200000-0x0021025F aren't usable either. There are also some issues with
> the parcels image sometimes taking the memory I want.
>
> Any ideas on what I could do to make my code usable on as many NewWorld
> machines as possible? I could rewrite the c as fcode, but that would be
> hard and annoying.
>

It's interesting that XCOFF in OF isn't relocatable. I remember reading
somewhere that earlier Apple OF implementation used to include very
primitive loader packages. I was told that this has been fixed in later
versions.

Is that true for any specific OF version or for ALL NW versions?

This is probably the reason why the Trampoline was supplied as ELF
container. I wonder how Apple's engineers performed XCOFF to ELF
conversion. MPW, used to compile the Trampoline, cannot produce ELF, at
least not with the publicly available release.

My bet is that a custom conversion tool similar to macho-to-xcoff in BootX
has been used for that purpose.

I assume that non-relocatable XCOFF doesn't present a problem in BootX...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20181025/f5d64d10/attachment.htm 


More information about the cdg5 mailing list