Date: Thu, 24 Mar 2016 10:51:15 +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: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> In-Reply-To: <CAByVWPVv4bWb4D3ccSteraP51=J8%2BJkc=Rze9O%2B64ov5%2B9tG8Q@mail.gmail.com> References: <CAByVWPVv4bWb4D3ccSteraP51=J8%2BJkc=Rze9O%2B64ov5%2B9tG8Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I=E2=80=99d slightly question the assertion that Mach-O is a = well-designed format. For example, it has a hard limit of 16 section = types, doesn=E2=80=99t support COMDATs and so on. OS X uses a load of = magic section names to work around these limitations. Note that a Mach-O image activator is relatively easy, but a Mach-O rtld = is far more complex. It might be possible to port dyld from OS X, but = as I recall it depends quite heavily on the Mach kernel interfaces. On fat binaries, note that the support in the file format is pretty = trivial. Far more support is needed in the image activator and rtld to = determine the correct parts and map only them. If you=E2=80=99re = interested in doing this work, then I=E2=80=99d recommend looking at = this proposed specification for fat ELF binaries: https://icculus.org/fatelf/ That said, I=E2=80=99m not totally convinced that fat binaries are = actually a good solution (unless you=E2=80=99re willing to go a step = further than Apple did and merge data sections) - NeXT managed very well = shipping fat bundles without using fat binaries and even had a special = mode in ditto to strip out the foreign architectures when copying a = bundle from a network share to a local filesystem. Persuading clang to emit FreeBSD Mach-O binaries is probably harder than = you think. It=E2=80=99s quite easy to persuade it that Mach is a valid = file format for FreeBSD, but there are a *lot* of places where people = conflate =E2=80=98is Mach=E2=80=99 with =E2=80=98is Darwin=E2=80=99 in = the Clang and LLVM sources. Finding all of these and making sure that = they=E2=80=99re really checking the correct one is difficult. Emulating OS X binaries may be interesting. NetBSD had a Mach / XNU = compat layer for a while. The problem here is that the graphics stack = interfaces on OS X are completely different from any other *NIX system = (as are the kernel interfaces for sound), so the most that they could do = was run command-line and X11 Mac apps - not especially useful. Actually = emulating OS X apps will need far more than that - OS X ships with about = 500MB of frameworks, many of which are used by most applications. The = GNUstep project is undermanned and hasn=E2=80=99t been able to keep up = with the changes to the core Foundation and AppKit frameworks, let alone = the rest. David > On 24 Mar 2016, at 09:13, mokhi <mokhi64@gmail.com> wrote: >=20 > Hi guys. > I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). >=20 > I am working on adding Mach-O binary format to supported formats for = FreeBSD. > Not for emulations on first step, but as a native supported format > just like a.out [or Elf] > (though it can go in both ways too). >=20 > There are good reasons to have Mach-O format support IMO. > It's well/clear designed file format. > Can supports multiple Arch by default (It's Fat Format). > Because of its Fat Format support, it can even help porting/packaging = easier for > projects such as Freebsd-arm or others IMO :D. > At end (even not among its interesting parts, maybe :D) point, it > leads and helps to have > OSX emulation support on FreeBSD. >=20 > BTW, i've coded[1] Mach-O support for FreeBSD with helps of > FreeBSD-ppl on IRC about various aspects of this works (from > fundamental points of VM-MAP, to SysEntVec for Mach-O format) and > with help of Elf and a.out format codes and mach-o references. > It's in Alpha state (or before it) IMO, as I'm not sure about some of > its parts, but I've tested a mach-o formatted binary with it and it at > least loads and maps it segments correctly :D. (it was actually a > simple "return 0" C Code, compiled in a OSX, if you know how can I > force my FreeBSD clang to produce mach-o files instead of ELF I'd be > happy to know it, and I appreciate :D) >=20 > I'd like to have your helps and comments on it, in hope to make it = better > and make it ready for review. >=20 > Thanks and thousands of regards, Mokhi. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [1] https://github.com/m0khi/FreeBSD_MachO > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7554521E-81AB-43DE-A7FC-A9F334F660B7>