3 ms·
Just because no one's done it before doesn't mean we're not allowed to do it. What Cosmopolitan Libc does is no different from any statically-linked binary on B
by jart 4y ago
Just because no one's done it before doesn't mean we're not allowed to do it. What Cosmopolitan Libc does is no different from any statically-linked binary on BSD, because they too use the SYSCALL instruction directly in a way that can't be changed at will by the operating system maintainers. The BSD operating systems do not forbid static linking. If you look at their syscalls.master files, a lot of time, particularly with ones like FreeBSD, you'll notice a large number of system calls which are only there to preserve backwards compatibility with statically linked binaries. It's really nice of them to do that.
When people talk about the supposed requirement to depend on the platform libc dso, what they're actually talking about is Apple frowning upon statically linked binaries. https://developer.apple.com/library/archive/qa/qa1118/_index.html https://developer.apple.com/library/archive/qa/qa1118/_index... They don't forbid it though, like Microsoft and Fuschia do. Fuschia for instance uses RIP origin detection. Windows does it by changing the RAX ordinals fortnightly. Apple simply asks that we say, hey, if you use Cosmo there's some risk Apple might break our binaries. We take proactive steps to avoid that happening with Cosmo. For example, we don't do some of the things Go did, like reverse engineering the memory layout of Apple's time functions. Cosmo sticks to the APIs that are shared by UNIXes in general, e.g. gettimeofday(), rather than depending on Apple's own internal designs, e.g. Mach system calls. I don't believe Apple can rightfully claim APIs that aren't their own, as being their own implementation detail which they can change at will. We do our best to respect Apple's boundaries, so I believe the risk of breakage with Cosmo on Apple should be minimal.
- catiopatio 4y ago> Cosmo sticks to the APIs that are shared by UNIXes in general, e.g. gettimeofday(), rather than depending on Apple's own internal designs, e.g. Mach system calls. Apple doesn't differentiate between "UNIX" and "Apple" when it comes to API; a particular API is either public with stability guarantees, or it is private and unstable. > I don't believe Apple can rightfully claim APIs that aren't their own, as being their own implementation detail which they can change at will. Apple absolutely does claim this, and if that means the library ABI has to change to accommodate a change, the dynamic linker and symbol tricks are leveraged to keep things working for code built against the earlier ABI. If an engineer comes up with a really clever trick to make gettimeofday() just a tiny bit faster, but this requires breaking syscall ABI, they will absolutely do that. > I believe the risk of breakage with Cosmo on Apple should be minimal. Using system-private interfaces on Apple platforms means there are no guarantees here. You'll be OK, sometimes, for some releases. It mostly worked for Go, for a while.
- jart 4y agoYes and then Apple smashed all of Google's toys. Cosmopolitan Libc isn't Google so I'm not sure why a disagreement between two megacorps concerns us.
- catiopatio 4y agoGoogle smashed their own toys; the approach was fundamentally flawed from the start, they tried to make a go of it anyway, it didn't work correctly (which they should have known would happen, and were repeatedly told it would), and they tossed out the idea and reimplemented it correctly. It's not "two megacorps" disagreeing, it's "supported interface" vs "unsupported, unstable, system-private interface".
- loup-vaillant 4y ago> Apple absolutely does claim this On paper. Have they acted on it? Have they actually broken an API that used to come standard with UNIX?
- lgg 4y agoYou are confusing API and syscall here. Apple tries incredibly hard to keep APIs (as implemented via libSystem) working, and actually has passed UNIX conformance, so generally speaking these work, are stable, and don't get broken. The underlying syscalls that support them have occasionally changed and broken existing apps that bypassed libSystem. For example, Sierra broke all go apps that called `gettimeofday` (the exact syscall jart used above an example!) because the go compiler emitted direct syscalls: https://github.com/golang/go/issues/16606 https://github.com/golang/go/issues/16606
- loup-vaillant 4y agoMy conflation of C API, C ABI, and syscalls was deliberate, though perhaps ill advised. I understood that Apple has some of the above marked as proprietary, that nevertheless come standard with UNIX. Probably not syscalls since those involves numbers & interrupts, but at least C ABIs. I'd like to know, did Apple actually break a "private" C ABI when this ABI actually implemented a standard UNIX function? I know they could, but did they?
- arghwhat 4y ago> Just because no one's done it before doesn't mean we're not allowed to do it. If you by "allowed" means "is meant to work", then yeah it means it's not allowed on many of these platforms. OpenBSD has infrastructure to control which memory regions syscalls are allowed to stem from, specifically designed to block syscalls from anything by libc. See https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ I do not recall if it was enabled, but when someone does not provide you an ABI it very much means that you are not supposed to try to write code against it. If you do it anyway, you will have to live with the resulting instability.