Hmm... On 2025-05-24 14:38, Mouse wrote:
Josh wrote: TL;DR: gcc produces corrupted kernel object files on a diskless, hardware KA$Mouse wrote: Do you have any particular reason to believe the hardware is not broken?Josh wrote: Good question... [...]Honestly, while possible, I seriously doubt there is a problem with the CPU module. If something was wrong there, I would expect way more things to be noticed than just some object files being corrupted while writing.In general, so would I. But I look at my VAX emulator and I notice how many instructions are unimplemented because I've never seen them used, and it seems plausible to me that there are a few instructions that are used only rarely, possibly only within the compiler (at least for the use cases tried so far).
It seems unlikely that it would be some instruction issue if the compilations fail on different files on repeated tries. In general, I would think it's very unlikely that some instruction would only occur when compiling a few files as well.
Also relevant is that the brokenness appears nondeterminstic. While it could be a mandelbug in the toolchain, I would expect something this blatant to be consistent if it's software.
I must admit that I must have missed it being non-deterministic. I thought it was the same files every time. If it is deterministic, I would point at the toolchain. If it in fact is non-deterministic, then hardware seems more likely.
And, when a simulated VAX doesn't exhibit the symptom? That substantially increase the plausibility of hardware issues, to me.
Again - if it is deterministic, I would suspect the toolchain. If not, then I'd also suspect hardware.
Not necessarily CPU issues. It could be, for example, flaky RAM. But my preferred suspect is hardware trouble of some sort.
I think I'd like to get some clarification on if this actually is non-deterministic.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol