Wait, it's not about addressability, but essentially about type confusion - typically data that is not actually a code pointer suddenly gets used as such by `ret`. If you are running on a machine that can push an integer but pop it as something else you're still in trouble. BTW, signed pointers are essentially a type check mechanism, where forging types is hard.
The activation records don't have to be stored in one piece: it's entirely possible to have a call stack that stores only return addresses and a data stack that stores frames of local variables (that's how you'd normally program e.g. on 6502). Which is a scenario that x64 arguably supports too, having separate RSP and RBP registers, with RBP-addressing being nice and easy and RSP-relative addressing encoded very cumbersomely.
Clang/LLVM supports such a scheme. It saves other variables that don't need to be dereferenced there too.
Many utilities on several BSDs are compiled with it, but are necessarily statically linked. <https://clang.llvm.org/docs/SafeStack.html>
The problem with these software-based approaches is that it is security-by-obscurity, which breaks if the address to the safe stack would leak. Like ASLR, it is considered more or less broken on 32-bit systems where it is easier to allocate significant portions of the address space to find where it is not and then do educated guesses.
However, there have been a few papers using Intel's MPK or even CET to protect it properly, at some performance cost of course.
It was also the model that Itanium used. You got the return address in a register and because register windows were saved to a separate stack, it thus saved the return address there too.
There's AMD shadow stack and Intel CET which do that as well. For compatibility, the return address is also on the data stack, but verified with the address stack.
CET complicates software virtual machines in several ways, e.g. deoptimization and exception handling. It's the wrong solution to a software problem that should never have arisen and just makes software even more complicated. An unfortunate metastasis of running unsafe code without checks for too long.
Funny that you use the term "x64", which is a technically incorrect way to refer to 64 bit x86 / amd64. If anything, "x64" refers to Alpha: 21064, 21164, 21264, 21364.
If the thing is widely being known as "x64", then "x64" is that thing's name. That's what the word "name" means.
And if you want to be picking nits, it's actually EM64T or at the very worst, IA-32e. Then again, there are actually two versions of this ISA and Intel is currently calling its version "Intel 64" (and AMD used to call their pre-release version "x86-64", by the way), but definitely not "64-bit x86".
Edit: Oh hey, you're the same guy who made that silly argument 11 months ago [0]. Never mind me then.
I sure hope you don't call those boxes full of electronics being discussed 'computers' since that's obviously a technically incorrect way to refer to them[1].
It's a good argument. If "everyone else does it" wasn't an effective argument against changing names, "oceanography" would've been rightfully renamed to "oceanology" by now.
You're the one who tried to make my post about the literal incorrectness of calling amd64 "x64" in a thread that also references Alpha, which is the correct usage of "x64", seem silly by saying that I'm referring to computers incorrectly because I'm referring to electronic computers, not human computers.
Now you want to pretend it's not an attempt at pedantry? I'm not sure why you WANT to be an asshole, but either disagree with me TECHNICALLY (that is, point out how "x64" is NOT and never was a reference to Alpha, and show evidence how "x64" somehow has always referred to amd64 outside of Windows-centric circles, and we can discuss that), or admit you're trying to be as wise-ass and don't be pedantic then get upset about me supposedly accusing you of being pedantic.
In other words, what do you really think you're bringing to the discussion? If you don't like when people point out incorrectness, then just say so.
There's a time and a place for making incorrect generalizations. Technical people shouldn't make incorrect generalizations when talking about technical things.
