Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cosmopolitan Libc: build-once run-anywhere C library

justine.lol

Post reply on HN
Print view View original

71–80 of 171 posts

Re: Cosmopolitan Libc: build-once run-anywhere C library

#71

Post by pjmlp »

moonchild wrote: post #42
ludocode wrote: post #36

Earlier quoted context omitted.

> Cosmopolitan only depends on stable kernel ABIs with long term stability promises Unfortunately, on macOS a stable kernel ABI does not exist. macOS has had kernel ABI breakage before, even recently, and they explicitly warn against making your own system calls. On Windows things are more stable but that's only because Windows cares about backwards compatibility to the point of preserving the behavior of even the mo…

Ntdll is the kernel ABI on windows; it is stable, and cosmopolitan uses it. Not sure what you mean by ‘on Windows thing are more stable’; syscall numbers change all the time. See https://j00ru.vexillium.org/syscalls/nt/64/

Ntdll is not meant to be used as public API, whatever works does so by pure luck.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#73

Post by pwdisswordfish5 »

andi999 wrote: post #62

Can somebody explain the whole thing to me? I know how to programm on windows and linux, but thats basically at the level of calling the compiler and linker, and some parameters to sometimes build a dll. So what does this do, and how does it work? Does it apply to DLLs as well? Also, 'run anywhere' means on the same processor type?

It’s a libc implementation accompanied by a linker script that tricks the linker into generating a polyglot executable file, simultaneously interpretable as an MZ executable, x86 boot sector and a Unix shell script, the latter of which re-writes the executable into ELF or Mach-O format and then executes it again. I haven’t analysed it all that thoroughly, but that’s the gist of it. Here’s more information: https://justine.storage.googleapis.com/ape.html

Polyglot files are not a particularly new invention, but devising a reproducible process to generate those can be quite tricky, so most don’t bother unless there’s a special need for it. (For example, the GRUB4DOS fork of GRUB contains a ‘bootlace’ executable that is simultaneously executable as a DOS .COM and an ELF file.)

The libc itself contains a number of specially-crafted functions and header files that expose the functions’ clobbered register set as part of the functions’ public ABI, which allows the compiler to use that knowledge to better allocate registers and optimise more aggressively. The downside is that if the clobbered register set changes, it requires everything using the function to be recompiled.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#74

Post by jart »

pjmlp wrote: post #70
jart wrote: post #34

Earlier quoted context omitted.

Author here. WebAssembly has played an important role protecting CI on the Internet and it's cool that it enables us to run LLVM in the browser. I was very surprised when I learned that some people were using it offline outside of browsers, since doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead, which might fix all the stuff that's built on top of C t…

> We can in fact have first-class portable native binaries, which will only require JIT compilation if they're launched on a non-x86 machine. This is nothing new, IBM and Unisys mainframes have been doing it since the 60's.

IBM System/360 and NexGen i586 were big inspirations for the design of Cosmopolitan.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#75

Post by morelisp »

aledthemathguy wrote: post #69
jart wrote: post #34

Earlier quoted context omitted.

Author here. WebAssembly has played an important role protecting CI on the Internet and it's cool that it enables us to run LLVM in the browser. I was very surprised when I learned that some people were using it offline outside of browsers, since doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead, which might fix all the stuff that's built on top of C t…

excuse my ignorance on this, but this sounds amazing. game changing. yet it's being "served" here on ice. casually. what am I missing?

WORA's been promised for decades. Even if it's true no one will believe it (including me). And portability is not the only reason people choose Rust or Go over C.

That's before you get into whether you can aesthetically convince everyone that x86-64 is good, actually.

Still very interesting though, especially compared to the usual Show HN crap.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#77

Post by etamponi »

This project sounds amazing and very interesting! I have one question: how does it work on bare metal? I tried to look for an explanation in the documentation but I couldn't find anything. The specific questions I have are:

1) How does this interact with a boot loader like GRUB? Or does it come with its own boot loader? But in this case, shouldn't this go in a specific location on the boot disk?

2) How does it handle io in bare metal mode? Specifically: sockets.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#78

Post by the-dude »

morelisp wrote: post #75
aledthemathguy wrote: post #69

Earlier quoted context omitted.

excuse my ignorance on this, but this sounds amazing. game changing. yet it's being "served" here on ice. casually. what am I missing?

WORA's been promised for decades. Even if it's true no one will believe it (including me). And portability is not the only reason people choose Rust or Go over C. That's before you get into whether you can aesthetically convince everyone that x86-64 is good, actually. Still very interesting though, especially compared to the usual Show HN crap.

Your comment would be better without the last sentence.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#80

Post by saagarjha »

mkup wrote: post #61
CyberDildonics wrote: post #9

Earlier quoted context omitted.

Even if you are trying to avoid the standard library, visual studio will insert memcpy into a loop that is just copying memory, then the linker will error out when it can't find it.

This is true, but it's possible to prevent this behavior by turning off optimizations for just one function (by adding ``#pragma optimize("g", off)'' before the function definition and ``#pragma optimize("g", on)'' after the function definition).

A better way to do with with GCC at least is -fno-builtin.
Post reply on HN