Re: KA655 Kernel Compile and Corrupt Object Files

Johnny Billquist <[email protected]>
Newsgroups gmane.os.netbsd.ports.vax
Organization SoftJAR AB
Message-ID <[email protected]>
Reading the original post again, I'm more perplexed.

Yeah, it do seem it is non-deterministic. But even more weird is that 
most object files come out differently (even when valid) on simh 
compared to real hardware. But both "valid".

Are the two systems really running the same toolchain? This just sounds 
more strange by the second...

Is gcc prone to now produce non-deterministic output?

   Johnny

On 2025-05-24 14:47, Johnny Billquist wrote:
> 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: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.