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

Thoroughly Understanding C++ ABI (2024)

ykiko.me

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Thoroughly Understanding C++ ABI (2024)

#81

Post by pjmlp »

aboardRat4 wrote: post #76
pjmlp wrote: post #17

Earlier quoted context omitted.

OS written the C, which is what many overlook. If you are on e.g. z/OS you would be using ILE, Integrated Language Environment, on ChromeOS JS/WASM, on Android either DEX or JNI,...

Android is Linux and it's written in C. Bionic is still a posix libc.

Android uses the Linux kernel as implementation detail, it could be changed with Zircon if Google cared, bionic is partially POSIX, only the required for ISO C, ISO C++, ART and NDK native APIs is exposed.

80% of Android APIs are exposed via Java, and even native ones have to use JNI.

Re: Thoroughly Understanding C++ ABI (2024)

#82

Post by pjmlp »

mort96 wrote: post #75
pjmlp wrote: post #74

Earlier quoted context omitted.

Nah, you are on a trolling vibe. All you need to do is clarify the first post on the thread with documentation. Sometimes I do miss these Usenet like rounds.

I genuinely did not understand that you were asking for documentation. I believe GNU follows the SysV ABI on amd64: https://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf

Which GNU OS was the point, there isn't any GNU OS, unless we talk about Hurd I guess.

That ABI is known for UNIX systems yes, although it isn't uniformly implemented, and again comes back to the whole OS written in C, like UNIX naturally is given it is the reason C exists in first place.

Which as mentioned, is not followed by every UNIX variant anyway.

Now GNU OS, still don't know what that is, Linux kernel with glibc?

Then again, using other libc doesn't require the same ABI.

Re: Thoroughly Understanding C++ ABI (2024)

#83

Post by p_l »

rramadass wrote: post #71
pjmlp wrote: post #65

Earlier quoted context omitted.

You definitely do, unless you are stuck in Windows XP view of computing world. It is like using ReactOS instead. All Windows APIs since Vista are delivered via COM. How much Windows development are you doing actually? Not that much apparently. Also someone has to surface Windows APIs to managed languages, they don't appear by magic.

> All Windows APIs since Vista are delivered via COM. Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstrac…

Every new API since around NT5.2/6.0 era had to get explicit waiver to be provided as anything other than COM interface. Some additionally have weird hybridization going on IIRC that lets you have some kind of faster path but still has COM exposed (IIRC that's only DirectX?)

That is for new APIs, not extensions of existing APIs.

IIRC, most non-COM methods you'll see for those are wrappers around COM calls. Back when WinRT was promoted as the next big thing, once you got outside of the small circle of WinRT propaganda there was explicit acknowledgement that all of the APIs are actually COM based enabling continued development of non-.NET compilers.

Of course underneath it all, especially once you get to userland-kernespace interactions you go back to combinations of IOCTL, memory mapped IO, some basic object calls and undocumented fun of OpenVMS-derived IPC, but a considerable chunk of that is not exposed or documented for non-blessed programmers.

Re: Thoroughly Understanding C++ ABI (2024)

#84

Post by p_l »

throwlifeaway wrote: post #47
WalterBright wrote: post #30

Earlier quoted context omitted.

> and a very specific vtable layout for COM objects Fun fact: Microsoft developed COM based on how Zortech C++ virtual functions worked. (It predated Microsoft C++ by years.)

You mean... using a vtable? Are you claiming to have invented the concept of vtables?

More like the specific design of a vtable

Re: Thoroughly Understanding C++ ABI (2024)

#85

Post by p_l »

pjmlp wrote: post #81
aboardRat4 wrote: post #76

Earlier quoted context omitted.

Android is Linux and it's written in C. Bionic is still a posix libc.

Android uses the Linux kernel as implementation detail, it could be changed with Zircon if Google cared, bionic is partially POSIX, only the required for ISO C, ISO C++, ART and NDK native APIs is exposed. 80% of Android APIs are exposed via Java, and even native ones have to use JNI.

Additionally a lot of the APIs if you go underneath, including native code components, are exposed through few variants of Binder (BeOS-derived IPC for the uninitiated) including userspace drivers.

Binder APIs very much do not follow C ABI other than the part where you deal with wrapper around ioctl()

Re: Thoroughly Understanding C++ ABI (2024)

#86

Post by p_l »

MFHava wrote: post #34
bluGill wrote: post #20

Earlier quoted context omitted.

The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the people who write that standard are very sensitive to the vendors and users of C++ who depend on a stable binary ABI. Thus they take extreme care to ensure that no change to the standard breaks binary ABI. The C++ standard did force gcc to break the ABI of std:…

> They then watched the gcc community work through 10 years of pain to make the transition. During the same time the MSVC compiler broke ABI multiple times and the world didn't end. The fact that breaking ABI was such a shitshow for libstc++ is more related to the way C++/ABI/SOs is/are handled in Linux...

The part where Windows applications built with C++ generally do not share C++ ABI DLLs with each other and the operating system except for certain well isolated ones is major part of it.

GCC changing C++ ABI usually meant horrific time for every C++ application on Linux unless you use something like Nix so you don't chance loading incompatible binaries.

Re: Thoroughly Understanding C++ ABI (2024)

#87

Post by aboardRat4 »

pjmlp wrote: post #81
aboardRat4 wrote: post #76

Earlier quoted context omitted.

Android is Linux and it's written in C. Bionic is still a posix libc.

Android uses the Linux kernel as implementation detail, it could be changed with Zircon if Google cared, bionic is partially POSIX, only the required for ISO C, ISO C++, ART and NDK native APIs is exposed. 80% of Android APIs are exposed via Java, and even native ones have to use JNI.

It's just demagoguery. Windows could switch to Linux kernel if Microsoft cared enough to invest into Wine. But this will not happen any time soon.

All smartphone drivers would have to be rewritten for a different kernel.

Re: Thoroughly Understanding C++ ABI (2024)

#88

Post by aboardRat4 »

p_l wrote: post #85
pjmlp wrote: post #81

Earlier quoted context omitted.

Android uses the Linux kernel as implementation detail, it could be changed with Zircon if Google cared, bionic is partially POSIX, only the required for ISO C, ISO C++, ART and NDK native APIs is exposed. 80% of Android APIs are exposed via Java, and even native ones have to use JNI.

Additionally a lot of the APIs if you go underneath, including native code components, are exposed through few variants of Binder (BeOS-derived IPC for the uninitiated) including userspace drivers. Binder APIs very much do not follow C ABI other than the part where you deal with wrapper around ioctl()

This is entirely unrelated to the point made.

Binder is just C++ with a thin IPC compiler, more or less similar to any IPC idl. Could be sunrpc, but Google wanted a c++ wrapper.

But in any case this is completely irrelevant, because there is no such thing as a "userspace driver" (unless you're speaking about hurd or plan9). Drivers are by definition kernel-space code (which on Linux is either built into the kernel, or is a loadable kernel module). Those binder wrappers are just a convenience layer, underneath it's all still Linux, /dev/video0, v4l2, and so on.

Post reply on HN