ELF itself is a disaster. Symbol lookup in ELF is process scoped, not
library scoped like Windows's PE and Mac's Mach-O, so same named
symbols from different libraries in the same process (loaded through
any number of levels of indirection) can and do clash, resulting in
memory corruption. This is why hacks like symbol versioning,
RTLD_DEEPBIND on GNU's libc and -Bdirect on Solaris were invented.

We suffer from this problem badly on FreeBSD, as Clang's C++ standard
library and GCC's standard library don't have fully compatible ABIs,
so when both are loaded into the same process and the incompatible C++
features are used -> memory corruption -> crash. Eg. compile Apache
OpenOffice with GCC on a system built with Clang, and you'll see even
the unit tests crash.

This is why I am personally interested in alternatives like Mach-O.


On Thu, Mar 24, 2016 at 12:51 PM, David Chisnall <thera...@freebsd.org> wrote:
> Hi,
> I’d slightly question the assertion that Mach-O is a well-designed format.  
> For example, it has a hard limit of 16 section types, doesn’t 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’re interested in doing this work, 
> then I’d recommend looking at this proposed specification for fat ELF 
> binaries:
> https://icculus.org/fatelf/
> That said, I’m not totally convinced that fat binaries are actually a good 
> solution (unless you’re 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’s quite easy to persuade it that Mach is a valid file format for 
> FreeBSD, but there are a *lot* of places where people conflate ‘is Mach’ with 
> ‘is Darwin’ in the Clang and LLVM sources.  Finding all of these and making 
> sure that they’re 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’t 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 <mokh...@gmail.com> wrote:
>> Hi guys.
>> I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends).
>> 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).
>> 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.
>> 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)
>> I'd like to have your helps and comments on it, in hope to make it better
>> and make it ready for review.
>> Thanks and thousands of regards, Mokhi.
>> ==============================
>> [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-unsubscr...@freebsd.org"
> _______________________________________________
> freebsd-emulat...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-emulation
> To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to