Vm-dev May 2020

vm-dev@lists.squeakfoundation.org

39 participants
130 discussions

[OpenSmalltalk/opensmalltalk-vm] DO NOT INTEGRATE - FOR DISCUSSION ONLY Minimalistic headless x64 msvc2017 (#312)
by Ben Coman 11 Sep '20

11 Sep '20

Ronie submitted a pull request that fixes the build with cygwin for win32 ( https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311 ) and I'm curious if any of my changes here are still applicable. @ronsaldo could you comment on these... You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312 -- Commit Summary -- * Fix function call declarations and return types (x64-msvc2017) * Fix unresolved external symbol 'alloca' (x64-msvc2017) * Workaround _controlfp() does not support _MCW_PC or _MCW_IC on x64. Expert review required. * Add architecture define _M_IX86 to ABI (x86-msvc2017) * Workaround hang allocating initial memory (x64-msvc2017). Expert review required. * Better 32bit CMakeLists.txt for SqueakFFIPrims (x86-msvc2017) -- File Changes -- M CMakeLists.txt (43) M platforms/Cross/plugins/IA32ABI/ia32abicc.c (2) M platforms/Cross/plugins/IA32ABI/x64win64abicc.c (3) M platforms/Cross/plugins/IA32ABI/xabicc.c (2) M platforms/minheadless/common/sqMain.c (1) M platforms/minheadless/windows/sqPlatformSpecific-Win32.c (9) M platforms/minheadless/windows/sqPlatformSpecific-Win32.h (2) M platforms/minheadless/windows/sqWin32Main.c (1) M platforms/minheadless/windows/sqWin32SpurAlloc.c (9) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312.diff -- 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/pull/312

5 12

[OpenSmalltalk/opensmalltalk-vm] Build on FreeBSD (#483)
by Jochen Raßler 11 Sep '20

11 Sep '20

I'm trying to build the squeak.cog.spur vm on FreeBSD 12.1 Steps I took so far: - build.linux64x64 - squeak.cog.spur - adding to mvm ``` case $(uname -s) in OpenBSD) CFLAGS="$CFLAGS -I/usr/local/include" LIBS="$LIBS -lexecinfo" LDFLAGS="$LDFLAGS -L/usr/local/lib" ;; FreeBSD) CFLAGS="$CFLAGS -I/usr/local/include" LIBS="$LIBS -lexecinfo -liconv" LDFLAGS="$LDFLAGS -L/usr/local/lib" ;; esac ``` to fix linking issue with libiconv - changed vm-sound-ALSA/sqUnixSoundALSA.c `static char devname[MAX_NAME_LEN]` to `static char a_devname[MAX_NAME_LEN]` and changed all occurences of devname to a_devname to fix a name resoltuion issue with /usr/include/stdlib Now I'm stuck with plugins/SqueakSSL/sqUnixOpenSSL.inc line 75 ``` /oscog/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc:75:18: error: variable has incomplete type 'struct in6_addr' struct in6_addr addr = { 0 }; // placeholder, longest of in_addr and in6_addr ``` Compiler is clang 8. Can you give me a hint how to move on? -- 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/483

5 6

[OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)
by Ken Dickey 10 Sep '20

10 Sep '20

I have built and tested aarch64 builds on Raspbery Pi 3B / Arch Linux / MUSL+Busybox Chromebook Two / Linux / libc The mvm "-O1" seems to work in both cases -- no need to go to "-O0" Please ignore the spurious sqSCCSVersion.h -- I don't know how to elide this. The getwd() -> getcwd() in sqUnixSecurityPlugin.c should likewise be harmless [no getwd() in MUSL] Not a time concern. I don't know of anyone asking for this. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450 -- Commit Summary -- * MUSL for AlpineLinux * MUSL for AlpineLinux -- File Changes -- M build.linux64ARMv8/squeak.stack.spur/build.debug/mvm (7) M build.linux64ARMv8/squeak.stack.spur/build/mvm (10) M platforms/Cross/plugins/sqPluginsSCCSVersion.h (8) M platforms/Cross/vm/sqSCCSVersion.h (14) M platforms/Cross/vm/sqVirtualMachine.c (5) M platforms/unix/plugins/SecurityPlugin/sqUnixSecurity.c (3) M platforms/unix/vm/sqUnixMain.c (5) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450.diff -- 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/pull/450

6 28

[OpenSmalltalk/opensmalltalk-vm] Be explicit about which test image version - move to CI config (#331)
by Ben Coman 10 Sep '20

10 Sep '20

First try to see what Travis thinks about these changes. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331 -- Commit Summary -- * Be explicit about which test image version - move to CI config -- File Changes -- M .travis.yml (91) M scripts/ci/travis_test.sh (6) M tests/smalltalkCI.sh (25) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331.diff -- 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/pull/331

3 4

[OpenSmalltalk/opensmalltalk-vm] Simplify gitignore build directories [skip ci] (#351)
by Ben Coman 10 Sep '20

10 Sep '20

I noticed that modified Makefiles weren't being pickup up by `git status`. It was too tedious trying to fix the existing definitions, so I've condensed them down to 4 lines from 34. I'm reasonably sure the result is the same, but if I've missed something its low impact, so maybe just integrate first to let everyone suck-n-see. Doing a `git status` before each `git commit` will let you confirm that its working. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351 -- Commit Summary -- * Simplify gitignore build directories -- File Changes -- M .gitignore (43) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351.diff -- 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/pull/351

2 2

[OpenSmalltalk/opensmalltalk-vm] third-party: Stop building/using vulnerable software (#386)
by Holger Freyther 10 Sep '20

10 Sep '20

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386 -- Commit Summary -- * third-party: Stop building/using vulnerable software -- File Changes -- M third-party/libgit2.spec (10) M third-party/libpng.spec (6) M third-party/libssh2.spec (6) M third-party/openssl.spec (6) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386.diff -- 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/pull/386

7 13

[OpenSmalltalk/opensmalltalk-vm] fix libgit2 makefile (#390)
by maenu 10 Sep '20

10 Sep '20

I am using MacPort's CMake which works fine, except that it needs a path argument for the libgit2 makefile. Can somebody check if this is compatible with their CMakes? You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390 -- Commit Summary -- * fix libgit2 makefile -- File Changes -- M build.macos64x64/third-party/Makefile.libgit2 (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390.diff -- 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/pull/390

2 2

[OpenSmalltalk/opensmalltalk-vm] Sunupdate (#496)
by David Stes 03 Sep '20

03 Sep '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, There's two updates for the SunOS port here. - - Change #define sk_GENERAL_NAME_freefunc for SunPRO C compiler - - SunOS: add a note in HowToBuild on pkg-config The first change is for the OpenSSL SqueakSSL case of openssl 1.0.2, to fix a type cast ... I think this potentially impacts all openssl 1.0.2 platforms that use --disable-dynamicopenssl but it seems OK (I think/hope). For the second change this is a "documentation" update to the HowToBuild "HOWTO" documentation in the build.sunos directory; this has no further impact. Thanks, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJes8ijAAoJEAwpOKXMq1MamV8H/2MrggX6VzRxGCdP40MN5vyE HuynHVCC68dLneHoYSvaMi4IrVGXS6lYMGa8FfNZsWuVCZDW/rii1nZNH9qo6zCM 6QRekLwKOpp63tXGpKj3C/e8skju6cPvCd9LGWguSqPUVHwFCqOSawYI4OEckvvr 6Nvnqk7ER2yE/iuJSeWgIRLVq4kE/Aq3x8wAtf7zgITHhxr8fEG5+H/Y7icKHW1J aTv2Z7jDHTcJqM/sEC0la2e8K2iDHkhKBim0K/PS1LtLgzZGAfycdmHJoq0KccRT gXpEHjsDIEdfvWmIU9xjIiwsIdg5Cz7l5Y7ipb8s1l5cZKv4ct5JnwBl2+Rw+MY= =oc8N -----END PGP SIGNATURE----- You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/496 -- Commit Summary -- * Merge pull request #4 from OpenSmalltalk/Cog * Merge pull request #5 from OpenSmalltalk/Cog * SunOS: add a note in HowToBuild on pkg-config * Change #define sk_GENERAL_NAME_freefunc for SunPRO C compiler -- File Changes -- M build.sunos64x64/HowToBuild (10) M platforms/unix/plugins/SqueakSSL/openssl_overlay.h (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/496.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/496.diff -- 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/pull/496

2 15

Win64 Builds broken, slow build times?
by Tom Beckmann 12 Aug '20

12 Aug '20

Hi everyone, I just tried building build.win64x64/squeak.cog.spur on the Cog branch but got a segfault on startup. I then tentatively went back 10 commits (HEAD~10) and it worked again. This is the output I received in gdb: Thread 1 received signal SIGSEGV, Segmentation fault. 0x00000000004016f3 in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:2809 2809 memset(theStackMemory, 0, stackPagesBytes); (gdb) bt #0 0x00000000004016f3 in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:2809 #1 0x000000000052c34c in sqMain (argc=2, argv=0x1dd53a0) at ../../platforms/win32/vm/sqWin32Main.c:1709 #2 0x000000000052c7f2 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0xfc437c "../../../Squeak6.0alpha-19582-64bit-202003021730-Windows/Squeak6.0alpha-19582-64bit.image", nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1802 #3 0x00000000004013c7 in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:339 #4 0x00000000004014cb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:195 The main reason I'm writing, however, is that I only haven't done a bisect yet because building the VM appears unusually slow, when compared to building on Linux, as in, orders of magnitude slower. I believe I have the same setup as we do on appveyor on windows using cygwin64. Incremental builds seem to recompile a lot of files and it appears there are race conditions when building with multiple threads (-j8). Are these known limitations of the Windows build or am I potentially just having the wrong setup? Thank you for any pointers! Tom

4 7

[OpenSmalltalk/opensmalltalk-vm] primitives 54 and 554 for timesTwoPower: answer incorrect result on 64bits macOS VM (#383)
by Nicolas Cellier 20 Jul '20

20 Jul '20

This is due to a macOS bug in 64bits libm! (Hard to believe, isn't it?) I've opened a ticket https://bugreport.apple.com/web/?problemID=48021471 > Area: > Something not on this list > > Summary: ldexp incorrectly rounds gradual underflow for some specific values. > > Steps to Reproduce: > #include <math.h> > #include <stdio.h> > int main() { > int exp=-54; double y=ldexp(11.0,exp); /* y is binary 1.011*2^-51 */ > double u=ldexp(1.0,-1074); /* u is the minimal denormalized IEEE754 double */ > double v=ldexp(y,-1023); /* v is binary 1.011*2^-1074 and should round to u */ > printf("u=%g v=%g\n",u,v); > return 0; > } > > Expected Results: > v should be rounded to 1.0*2^-1074 (round to nearest, tie to even default rule) > Thus we should have u == v. > > Actual Results: > v is rounded upward to binary 10.0*2^-1074 = 1.0*2^-1073 > output is u=4.94066e-324 v=9.88131e-324 > > Note 1: this fails for 4 different values of exp -54,-53,+968,+969 > (replace exponent -1023 by -1074-3-exp, that is -1023,-1024,-2045,-2046) > Note 2: this did not happen previously with 32bits libm version. > Note 3: this sounds a bit like this bug https://stackoverflow.com/questions/32150888/should-ldexp-round-correctly > > Version/Build: > macOS HighSierra 10.13.16 > > Configuration: > compiled with > clang --version > Apple LLVM version 10.0.0 (clang-1000.11.45.5) > Target: x86_64-apple-darwin17.7.0 > Thread model: posix > InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > Xcode Version 10.1 (10B61) > > -- 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/383

5 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2020