Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Mar 2016 12:21:23 +0000
From:      David Chisnall <theraven@FreeBSD.org>
To:        mokhi <mokhi64@gmail.com>
Cc:        emulation@freebsd.org, current@freebsd.org
Subject:   Re: FreeBSD MachO File format, your comments on it.
Message-ID:  <FA836779-BA60-4563-A2DA-4038A5BE15D8@FreeBSD.org>
In-Reply-To: <CAByVWPVYYkZQZtwF10%2BfA8rDbofer-3PRYN37y-OCrnpuX2guw@mail.gmail.com>
References:  <CAByVWPVv4bWb4D3ccSteraP51=J8%2BJkc=Rze9O%2B64ov5%2B9tG8Q@mail.gmail.com> <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> <CAByVWPVYYkZQZtwF10%2BfA8rDbofer-3PRYN37y-OCrnpuX2guw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Mar 2016, at 12:05, mokhi <mokhi64@gmail.com> wrote:
>=20
> Hi.
>=20
> I'm agreed with point you told about improvements we can do for fat
> format (or more).
> And I'm ready to do them (with your helps, sure :D).
>=20
> But we need short steps and more of them (a local proverb :D) IMO.
> If we completely do this image activator, then we can have 2 sub plans
> for OSX emulation and/or fat data segment redesign.

FatELF binaries do not depend on this work.  Fat Mach-O binaries do, but =
the pain of working with Mach-O is not worth it (talk to some of the =
Apple toolchain team some time about how much effort Mach-O is - I=E2=80=99=
m glad it=E2=80=99s their problem and not mine).

I don=E2=80=99t believe that the work to support FatELF would be =
particularly large.  The format is pretty simple (basically a small =
header that tells you where within the binaries to find the real ELF for =
your architecture).  Teaching all of the associated bits of the =
toolchain (especially debuggers) about it is a lot of tedious work, but =
not particularly hard if someone is motivated to do it.  Teaching clang =
and lld to produce fat binaries as part of normal ELF compilation would =
be a bit more work.

> I saw netbsd's way of mach-kernel/darwin emulation.
> They have been stopped in porting/simulating quartz (the reason
> described lack of developers' interest IIRC), and that relates to OSX
> emulating.

That wasn=E2=80=99t the only reason.  The XNU kernel interfaces for =
graphics and sound are large and mostly undocumented (at least, =
publicly) and change between OS X revisions.  Even if you implement =
*all* of this, then you=E2=80=99d still need most of an OS X userland to =
be able to run OS X applications.  This would involve violating the OS X =
EULA unless you ran it on a Mac and the only thing that you=E2=80=99d =
then be able to do that you couldn=E2=80=99t with OS X is run FreeBSD =
binaries in the background or in XQuartz (which you can already do =
pretty well with xhyve on OS X).  If you are willing to violate the OS X =
EULA then you should probably just run OS X in a VM.

> If we wanna complete/continue that way, first we need this image
> activator, what's your opinion about it?
>=20
> BTW, in brief I believe we can have strategies to do (sub plans) and
> it worth (at least for me, because I'll learn good things). What's
> your opinion?

As a learning exercise, I definitely encourage you to continue.  Writing =
a new image activator will teach you a lot.  If you want to do some of =
the rtld work to make a partial Mach-O rtld then you=E2=80=99ll learn =
even more.  I just don=E2=80=99t think that the end result will be =
something that=E2=80=99s particularly useful to anyone.

David




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FA836779-BA60-4563-A2DA-4038A5BE15D8>