On 17-Feb-16 14:59, Paul Koning wrote: >> On Feb 17, 2016, at 2:53 PM, Timothe Litt <[email protected]> wrote: >> >> On 17-Feb-16 14:48, Michael Huff wrote: >>> I grabbed simh_master.zip from github yesterday and compiled it on OSX >>> and in a virtualbox instance of Linux Mint 17. OSX is the native OS, >>> Linux is in a VM. >>> >>> I have a 43BSD machine accessible to both on a shared drive. It will >>> boot normally when I run vax780 inside of the Linux VM, but when I >>> run the vax780 binary I compiled in OSX it crashes. >>> >> If I had to guess, it would be that the shared drive is not presenting >> the same data to both environments. >> >> Perhaps it's treating the binary file as text and adding <CR><LF>s -- or >> some such. >> >> I'd checksum the file from both sides before assuming it's a SimH issue. > That is a good test, certainly. But OSX is Unix, so it shouldn't suffer from > the sort of Windows-style misbehavior you mentioned. I know. But it does depend on how the file is shared, and from where. Is the real file on OSX? On Windows? On an NAS? Shared over SMB? NFS?
Especially SMB has been known to do very strange things. Well, I see that md5sums match, so it's not that this time. > I wonder if it might be a compiler bug. It would be instructive to download > gcc and use that to build the OSX based SIMH, to see if it behaves > differently. Yup. The symptom looks like data corruption. The instruction at the faulting PC is not likely a real one. > paul > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
