[Discuss] MS Buys GitHub

[Cy Schubert]

In message <nycvar.QRO.7.76.1806081557470.4349 at zreyva.zlyna.ubzr>, 
"Alan W. Irw
in" writes:
> On 2018-06-08 14:45-0700 Cy Schubert wrote:
>
> [....]
> > A good example [of an ABI difference] might be if the ordering of a struct 
> has
> > changed but not the contents. The API (source code interface) remains
> > the same but the ABI (binary code interface) is different.
>
> Nice example, Cy.
>
> And I am sure you know all about this, but for the benefit of the rest
> here, the other ABI incompatibility example that I have run into in
> the past as a cross-platform developer is that for *the same code*
> different compilers and even different versions of the same compiler
> can store the same information in different ways ==> ABI
> incompatibility.  So for example, the GTK+ developers make their suite
> of libraries available on Windows, but if you don't use a compiler
> with the same ABI to build your GTK+ application, then you get
> segfaults at run time due to that ABI incompatibility.

Correct. Also optimization. 
>
> Note, that Linux distributions are generally extremely aware of ABI
> issues that are caused by compiler version changes so it is rare to
> see such issues on Linux distributions.

As do we on the FreeBSD project. The following code fragment in 
kern_thread.c is an example of maintaining the KBI (kernel binary 
interface -- the interface kernel modules use):

#ifdef __amd64__
_Static_assert(offsetof(struct thread, td_flags) == 0xfc,
    "struct thread KBI td_flags");
_Static_assert(offsetof(struct thread, td_pflags) == 0x104,
    "struct thread KBI td_pflags");
_Static_assert(offsetof(struct thread, td_frame) == 0x470,
    "struct thread KBI td_frame");
_Static_assert(offsetof(struct thread, td_emuldata) == 0x518,
    "struct thread KBI td_emuldata");
_Static_assert(offsetof(struct proc, p_flag) == 0xb0,
    "struct proc KBI p_flag");
_Static_assert(offsetof(struct proc, p_pid) == 0xbc,
    "struct proc KBI p_pid");
_Static_assert(offsetof(struct proc, p_filemon) == 0x3d0,
    "struct proc KBI p_filemon");
_Static_assert(offsetof(struct proc, p_comm) == 0x3e4,
    "struct proc KBI p_comm");
_Static_assert(offsetof(struct proc, p_emuldata) == 0x4b8,
    "struct proc KBI p_emuldata");
#endif

_Static_assert is defined as:

	http://en.cppreference.com/w/c/language/_Static_assert

In the above example, if the listed members of their respective structs 
are not at the hardcoded offsets, the compile will fail. It's easier to 
resolve compile time failures than applications that fail or kernels 
that panic.

BTW, just as applications have an API and ABI, within the kernel, 
kernel programmers use the KPI (kernel programming interface), and 
kernel binaries the KBI. Thus third party software vendors and 
suppliers of hardware can ship kernel modules and be reasonably assured 
that what they ship won't panic a system.

In the example above someone added a member to a struct (I can't 
remember which one now) which would have broken KBI (and probably also 
ABI) compatibility. Fortunately _Static_assert caused the compile to 
fail and people simply sent him some nastygrams. The alternative could 
have been much worse: a panicking operating system which would have 
been harder diagnose.

You'll notice this with Oracle ASM modules too. Oracle supplies 
different ASM kernel modules for different minor versions of kernels 
distributed by major vendors such as Red Hat. When you patch the kernel 
you need to update your Oracle ASM.

>  However, recently a PLplot
> colleague of mine ran into exactly such an issue on the
> MinGW-w64/MSYS2 distribution of free software for Windows.  But the
> developers of that distribution are fairly new to the game so such
> MinGW-w64/MSYS2 ABI issues can be forgiven if they learn quickly to be
> a lot more cautious about how they change gcc compiler suite versions.




-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.