Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
Newsgroups: comp.os.vms
Subject: Re: New VSI blog post
Date: Tue, 30 Jul 2024 11:54:35 -0400
Organization: HoffmanLabs LLC
Lines: 48
Message-ID: <v8b2br$13k5b$1@dont-email.me>
References: <v899gl$mggt$1@dont-email.me> <e2e8638b95e119c998fa3f01849f4e75e2c46b58@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 30 Jul 2024 17:54:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8ecd9936cbba013aeecf5e6a33ae4155";
	logging-data="1167531"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX183zo7rLD02iOg9u4THIgY6XBettRjsJrc="
User-Agent: Unison/2.2
Cancel-Lock: sha1:cXT0Mif8/1Fm02XrV8UCFR/VmMc=
Bytes: 3377

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