Re: New VSI blog post

On 2024-07-30 03:28:16 +0000, John Reagan said:

And in lieu of an actual porting guide, I've been asked about "what things are catching people porting code from Itanium to x86".  Other than bugs in the compilers and OS, the most common issue I've seen is a mismatch of 32/64 bit variables.  I've seen 20 or so instance of code that is doing a 64-bit write into a 32-bit variable.  On Alpha and Itanium, GEM would allocate 32-bit variables into their own quadword on the stack.  Back in the old Alpha days, quadword granularity was very important.  It became less important on later Alphas and Itanium but still had limited benefit.  For x86, there is no reason for it and LLVM will just allocate 32-bit variables on the stack right next to each other.  The overwrite on Alpha/Itanium would just touch that extra alignment hole.  On x86, the overwrite clobbers the adjacent variable. It mostly has been in BLISS and C code.

?
BLISS has ample opportunities for foot-guns, but C usually flags integer or float mismatches that would lead to overflows or truncations. Which leaves buffers and strings.
I've certainly clobbered storage loading ten kilograms of data into a five kilogram malloc, among other sorts memory management "fun".
Given compiler errors are called out separately, and given examples of errors aren't offered, and given as few as roughly twenty cases found across ~everything, this seems like device drivers or kernel shenanigans with builtins or asm or such, or incorrect casting, or errant memcpy or lib$movc calls or ilk, or a strcpy that null terminates a four-byte transfer into the fifth byte, or maybe just buggy C code built with compiler diagnostics detuned or disabled. I'm guessing the errors specific to the sorts of things some hunk of OpenVMS C or BLISS is usually doing. Maybe a wrong size constant somewhere? Or a strcpy into a longword that spills the null?
What amounts to tearing when adjacent variables were within the same granularity was a wonderfully subtle and gnarly mess with asynchronous code aeons ago. But that doesn't fit the description here.
Given few cases and no examples, I'm assuming it's just some brain-cramp or another, and not a generic issue. Ports do traditionally tend to expose packing and padding issues, too.
--
Pure Personal Opinion | HoffmanLabs LLC