The ABI status of ELF hash tables

Posted Aug 19, 2022 17:40 UTC (Fri) by pbonzini (subscriber, #60935)
In reply to: The ABI status of ELF hash tables by NYKevin
Parent article: The ABI status of ELF hash tables

Any statically linked program, which includes any Go program, is essentially shipping its own libc.

The ABI status of ELF hash tables

Posted Aug 19, 2022 19:26 UTC (Fri) by int19h (guest, #159020) [Link] (4 responses)

Yes, which is why Go binaries were broken on macOS and FreeBSD for a long time, because it directly used a private API (syscalls) instead of libc. Here's an example:

https://github.com/golang/go/issues/16606

The only OS on which you can statically link libc and expect your binaries to work in future releases is Linux.

The ABI status of ELF hash tables

Posted Aug 19, 2022 20:14 UTC (Fri) by fw (subscriber, #26023) [Link] (2 responses)

Even the last part about Linux isn't totally true. The x86-64 kernel interface for getcpu and gettimeofday has already changed once for many users, breaking old glibc versions before 2.15 (and presumably statically linked binaries).

The ABI status of ELF hash tables

Posted Aug 19, 2022 21:47 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

Do you have a source for this? The kernel ABI is considered sacrosanct to the point that obsolete system calls from the early days of Linux are still around. I'd be surprised if they allowed a system call interface change that broke something as important as glibc.

The ABI status of ELF hash tables

Posted Aug 20, 2022 6:40 UTC (Sat) by izbyshev (guest, #107996) [Link]

The GP most likely refers to CONFIG_LEGACY_VSYSCALL_NONE enabled in Debian Buster[1] and some other distros (and even WSL kernels on Windows[2]), which is indeed an ABI-breaking change (e.g. gettimeofday() crashes on older glibc, breaking use cases like running containers with older distros).

But it's important to understand that it's not the upstream kernel that broke the ABI (in the default configuration) in this case. On the contrary, they introduced a new mode to improve security while preserving (most of) ABI compatibility[3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852620
[2] https://github.com/microsoft/WSL/issues/4694
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

The ABI status of ELF hash tables

Posted Aug 19, 2022 23:29 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

And were even somewhat broken on Linux if they used setuid - the system call doesn't (and isn't required to) follow the POSIX semantics, and it's up to libc to deal with that (https://github.com/golang/go/issues/1435)

statically-linked Go programs and libc

Posted Aug 19, 2022 20:14 UTC (Fri) by dkg (subscriber, #55359) [Link] (1 responses)

@pbonzini wrote:

> Any statically linked program, which includes any Go program, is essentially shipping its own libc.

Are you sure about this? gosop is a Go program, and all the Go bits are statically-linked, but it still dynamically loads libc

0 dkg@alice:~$ ldd $(which gosop)
	linux-vdso.so.1 (0x00007ffe414fd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdedda00000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdeddcc5000)
0 dkg@alice:~$

statically-linked Go programs and libc

Posted Aug 19, 2022 20:36 UTC (Fri) by dtlin (subscriber, #36537) [Link]

Depends on how it is built. cgo will use libc, but if a binary is built with CGO_ENABLED=0, then

$ ldd /usr/bin/tailscale
	not a dynamic executable

The ABI status of ELF hash tables

Posted Aug 20, 2022 23:30 UTC (Sat) by LtWorf (subscriber, #124958) [Link]

You never ran ldd on a go program uh?

They do link libc