Stephane Rollandin reported this:
> I have had a report that the code for my Balloon3D-based game (at
> http://www.zogotounga.net/comp/guardians.htm) does not work at all on
> 64-bit images.
>
> The report was about a linux system, and indeed I could confirm that it
> also applies on Windows.
>
> I have uploaded a ready-to-crash trunk image here, with instructions:
> http://www.zogotounga.net/swap/crash-64.zip
>
> Note that no crash dump is produced.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/468
I want to simulate VM from a Spur64VMMaker.image
Unfortunately, it gets really difficult to compile Bochs plugins these days...
WINDOWS (cygwin64):
$ cd processors/IA32/winbochs/
$ source ./conf.COG
> checking build system type... ../bochs/config.guess: unable to guess system type
>
> This script, last modified 2002-03-20, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
>
> ftp://ftp.gnu.org/pub/gnu/config/
>
> If the version you run (../bochs/config.guess) is already up to date, please
> send the following data and any information you think might be
> pertinent to <config-patches(a)gnu.org> in order to provide the needed
> information to handle your system.
>
> config.guess timestamp = 2002-03-20
>
> uname -m = x86_64
> uname -r = 3.0.7(0.338/5/3)
> uname -s = CYGWIN_NT-10.0
> uname -v = 2019-04-30 18:08
>
> /usr/bin/uname -p = unknown
>
MAC (Darwin 17.7.0 Xcode 10.1):
$ cd processors/IA32/macbochs
$ ./conf.COG
> checking build system type... i386-apple-darwin17.7.0
> checking host system type... i386-apple-darwin17.7.0
> checking target system type... i386-apple-darwin17.7.0
> checking if you are configuring for another platform... no
> checking for standard CFLAGS on this platform... -fpascal-strings -fno-common -Wno-four-char-constants -Wno-unknown-pragmas -Dmacintosh
> checking for gcc... gcc
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> cp config.h bochsconfig.h
> cp: config.h: No such file or directory
> and don't forget to run ../bochs/makeem
LINUX (Ubuntu 18.04 thru WSL)
$ cd processors/IA32/linuxbochs
$ ./conf.COG
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking if you are configuring for another platform... no
> checking for standard CFLAGS on this platform...
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
> cp config.h bochsconfig.h
> cp: cannot stat 'config.h': No such file or directory
> and don't forget to run ../bochs/makeem
The problem is that the Bochs copy is super old. So we won't get support for compilation on uptodate machines...
We cannot upgrade easily, since there are COG specific changes requiring to be replayed...
`grep -r COG processors\IA32`.
I also have doubts about the `conf.COG` files:
is `--disable-x86-64` really what we want?
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e77147b63208fb40a9a1…https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/processors/IA32/…
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/427
Hello,
I have a small issue when building (cross-compile) the Smalltalk VM on an ARM(v6) embedded linux system (Nano Pi neno and Raspberry Pi Zero) that uses Musl as default libc implementation.
The problem is that the code and the configure script does not have official support for Musl, so I created a patch file that adds support to Musl, you can find the [patch here](https://github.com/lxsang/antix/blob/master/sm_vm_musl.patch).
With this patch, i am able to cross-compile on the ARM toolchain for my system; with 4 plugins:
```
FilePlugin \
SqueakSSL \
SqueakFFIPrims \
SocketPlugin
```
You can find the build [script here](https://github.com/lxsang/antix/blob/master/packages/smalltalk-nano-p…
For now, i can live with this dirty trick, but i would be verry happy if the mainline VM has official support to Musl.
That's why i create this issue.
Thanks
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/304
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 8619b6f7e9384acd8066fb2a6f4d691ed126c528
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/8619b6f7e9384acd80…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2020-01-31 (Fri, 31 Jan 2020)
Changed paths:
M build.macos64x64/gdbarm64/conf.COG
M processors/ARM/gdb-8.3.1/sim/aarch64/cpustate.c
M processors/ARM/gdb-8.3.1/sim/aarch64/cpustate.h
M processors/ARM/gdb-8.3.1/sim/aarch64/simulator.c
Log Message:
-----------
ARMv8 simulator: implement 16-byte alignment checking (!!). If the SA0 bit is
set in SCTLR_EL0 (and this is the case on e.g. Manjaro ARMv8) then any attempt
to load or store throguh the sp if the sp is aligned on other than a 16 byte
boundary will produce an illegal instruction fault.
[ci skip]