Clang and GCC disagree on the ABI of __int128 (and its various unsigned/_t variants) on x64 linux (at least).
The issue is that when pushing __int128 to the stack, clang only aligns to 8, even though in structs it's aligned to 16.
This causes Clang and GCC to disagree on the offset for by-value __int128 arguments that need padding to be 16-aligned.
The following function signature demonstrates this in practice:
void i128_val_in_0_perturbed_small(
uint8_t arg0, | // Experimental sketches of specifying abi-checker tests with kdl. | |
| // See: https://github.com/Gankra/abi-checker | |
| // | |
| // Basically we generate source code for different languages (c, rust, ...) | |
| // from these abstract type/function definitions and then have them call eachother | |
| // and check that the values didn't get corrupted along the way. | |
| // Custom type definitions we want to pass across the ABI/convention of interest. | |
| // |
Building GeckoView on WSL(2) basically works out of the box like building it natively on Linux with mach.
Running your build is the real issue.
You generally have two options for running:
Trying to launch an emulator is likely to run into KVM errors, although apparently this has been fixed in the latest versions of Windows 11 (haven't confirmed).
| echo "hello 😺 मनीष بسم 好あaa" && echo "aaaaaaaaaaaaaaaaaaaaaaaa" |
% Swift and the Price of ABI Stability
For those who don't follow Swift's development, ABI stability has been one of its most ambitious projects, and it finally shipped in Swift 5. The result is something I find endlessly fascinating, because I think Swift has pushed the notion of ABI stability farther than any language with minimal compromise.
This article is broken up into two sections: background and details. Feel free to skip to the details if you're very comfortable with the problems inherent to producing a robust dynamically linked system interface.
If you aren't comfortable with the basic concepts of type layouts, ABIs, and calling conventions, I recommend reading the article I wrote on [the basic concepts of type layout and ABI as they pertain to Rust][rust-abi].
| Painting --- compositing layer tree: | |
| LayerManager (0x164ce420400) --- in 3D-sorted rendering order | |
| ContainerLayerMLGPU (0x164c4441800) [shadow-visible=< (x=0, y=0, w=3205, h=2017); (x=0, y=2017, w=3162, h=4826); >] [visible=< (x=0, y=0, w=3205, h=2016); >] [opaqueContent] [metrics0={ [metrics={ [cb=(x=0.000000, y=0.000000, w=3205.000000, h=2016.000000)] [sr=(x=0.000000, y=0.000000, w=1282.000000, h=806.400024)] [s=(0,0)] [dp=(x=0.000000, y=0.000000, w=1282.000000, h=806.400024)] [cdp=(x=0.000000, y=0.000000, w=0.000000, h=0.000000)] [scrollId=3] [z=2.5] }] [color=rgba(0, 0, 0, 0.000000)] }] [presShellResolution=1] | |
| PaintedLayerMLGPU (0x164c4445800) [shadow-visible=< (x=0, y=0, w=3205, h=2016); >] [visible=< (x=0, y=0, w=3205, h=2016); >] { hitregion=< (x=0, y=0, w=3205, h=2016); > dispatchtocontentregion=< (x=100, y=2, w=2660, h=83); >} [opaqueContent] [valid=< (x=0, y=0, w=3205, h=2016); >] | |
| ContentHost (0x164c440da60) [buffer-rect=(x=0, y=0, w=3205, h=2016)] [buffer-rotation=(0,0)] | |
| ShmemTe |
Initial LLVM-dev post on Swift calling convention: https://lists.llvm.org/pipermail/llvm-dev/2016-March/096250.html
Swift ABI Docs: https://github.com/apple/swift/tree/master/docs/ABI
C++ Lightweight Exceptions Proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf
| /// Generate a color ramp filling the indices in [start_idx, end_idx) and interpolating | |
| /// from start_color to end_color. | |
| fn fill_colors( | |
| start_idx: usize, | |
| end_idx: usize, | |
| start_color: &PremultipliedColorF, | |
| end_color: &PremultipliedColorF, | |
| entries: &mut ArrayVec<[GradientDataEntry; GRADIENT_DATA_SIZE]>, | |
| ) { | |
| debug_assert_eq!(start_idx, entries.len()); |
by 0xabad1dea September 2018
You may notice a decidedly Nintendo bias to the examples. I can't change who I am.
Speedrunning is:
My mental model of Initialization and Deinitialization:
This is kind've a brain dump of concepts, and does not necessarily represent a well-defined and minimized model. For instance, it's not clear to me if deinitialized memory is a "real" thing, or just a concept I like to have to think about dropped memory.
There are 3 (5) states a bit can have: uninit, init (0 or 1), deinit (0 or 1)
Freshly allocated memory is uninit. mem::unitialized() produces uninit.
Initializing memory makes it init with a definite value.