Vm-dev June 2020

vm-dev@lists.squeakfoundation.org

23 participants
106 discussions

[OpenSmalltalk/opensmalltalk-vm] 324578: Use libssh2 1.9.0 which has been fixed to compile ...
by Nicolas Cellier 17 Jun '20

17 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 32457868b9017b018e1c8a155af34497be34de1f https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32457868b9017b018e… Author: Nicolas Cellier <nicolas.cellier(a)sirehna.com> Date: 2020-06-17 (Wed, 17 Jun 2020) Changed paths: M third-party/libssh2.spec Log Message: ----------- Use libssh2 1.9.0 which has been fixed to compile with OpenSSL 1.1 See the release notes https://github.com/libssh2/libssh2/blob/master/RELEASE-NOTES Compilation should have failed since we upgraded OpenSSL. It seems that they succeeded only because they did not happen. That's because the result of previous compilation is cached. The failure is differed until the cache is cleaned, which happens on regular time basis. How fragile...

1 0

[OpenSmalltalk/opensmalltalk-vm] eb9686: Retry allow failures of individual pharo rows
by Nicolas Cellier 17 Jun '20

17 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: eb9686cf731d613d6c8379e5a23dac6e6e4af1f1 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/eb9686cf731d613d6c… Author: Nicolas Cellier <nicolas.cellier(a)sirehna.com> Date: 2020-06-17 (Wed, 17 Jun 2020) Changed paths: M .travis.yml Log Message: ----------- Retry allow failures of individual pharo rows

1 0

Errored: OpenSmalltalk/opensmalltalk-vm#2093 (Cog - 69a6ef7)
by Travis CI 17 Jun '20

17 Jun '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2093 Status: Errored Duration: 20 mins and 13 secs Commit: 69a6ef7 (Cog) Author: Nicolas Cellier Message: Allow build failure of pharo.cog.spur flavor Hi all, for some time and some unknown reason, pharo builds started to fail while building libssh2-1.7.0 on unix OSes There is considerable time and resources wasted building always the same libraries, and fragile cache strategies deployed to workaround the problem. To my knowledge, these failures are completely un-related to VMMaker changes, and probably not to platforms changes either. It might be related to cache handling (rather the success might be due to the cache preserving previous success...). The pharo fork changed their strategy and now download pre-build binaries rather than rebuilding them, which is a very wise decision. So, pharo folks, if you are interested in pharo builds from the root opensmalltalk-vm, please help debug current build and backport those vital changes. If no one speaks up, we consider those builds as non essential. Thanks for eventual support. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/032cecd91c6c...69… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/69929446… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[OpenSmalltalk/opensmalltalk-vm] 69a6ef: Allow build failure of pharo.cog.spur flavor
by Nicolas Cellier 17 Jun '20

17 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 69a6ef7234ccd60f82135235def7606d56f3ebb1 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/69a6ef7234ccd60f82… Author: Nicolas Cellier <nicolas.cellier(a)sirehna.com> Date: 2020-06-17 (Wed, 17 Jun 2020) Changed paths: M .travis.yml Log Message: ----------- Allow build failure of pharo.cog.spur flavor Hi all, for some time and some unknown reason, pharo builds started to fail while building libssh2-1.7.0 on unix OSes There is considerable time and resources wasted building always the same libraries, and fragile cache strategies deployed to workaround the problem. To my knowledge, these failures are completely un-related to VMMaker changes, and probably not to platforms changes either. It might be related to cache handling (rather the success might be due to the cache preserving previous success...). The pharo fork changed their strategy and now download pre-build binaries rather than rebuilding them, which is a very wise decision. So, pharo folks, if you are interested in pharo builds from the root opensmalltalk-vm, please help debug current build and backport those vital changes. If no one speaks up, we consider those builds as non essential. Thanks for eventual support.

1 0

Errored: OpenSmalltalk/opensmalltalk-vm#2092 (Cog - 032cecd)
by Travis CI 16 Jun '20

16 Jun '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2092 Status: Errored Duration: 19 mins and 24 secs Commit: 032cecd (Cog) Author: Eliot Miranda Message: Move the mkNamedPrims.sh script to platforms/Cross/util. Add platforms/Cross/util/mkIntPluginIndices.sh, a script to generate defines for builtin plugins such that each builtin plugin name is defined as its position in the sequence of plugins. This is useful for e.g. a common logging facility that needs to output to a different log file for each plugin. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/eb087cf5610c...03… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/69877175… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[OpenSmalltalk/opensmalltalk-vm] 032cec: Move the mkNamedPrims.sh script to platforms/Cross...
by Eliot Miranda 16 Jun '20

16 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 032cecd91c6cf4fdb6549b7e3693648211e513ab https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/032cecd91c6cf4fdb6… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-06-15 (Mon, 15 Jun 2020) Changed paths: M build.macos32x86/common/Makefile.vm R build.macos32x86/common/mkNamedPrims.sh M build.macos64x64/common/Makefile.vm R build.macos64x64/common/mkNamedPrims.sh A platforms/Cross/util/mkIntPluginIndices.sh A platforms/Cross/util/mkNamedPrims.sh Log Message: ----------- Move the mkNamedPrims.sh script to platforms/Cross/util. Add platforms/Cross/util/mkIntPluginIndices.sh, a script to generate defines for builtin plugins such that each builtin plugin name is defined as its position in the sequence of plugins. This is useful for e.g. a common logging facility that needs to output to a different log file for each plugin.

1 0

Errored: OpenSmalltalk/opensmalltalk-vm#2091 (Cog - eb087cf)
by Travis CI 16 Jun '20

16 Jun '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2091 Status: Errored Duration: 20 mins and 7 secs Commit: eb087cf (Cog) Author: Eliot Miranda Message: CogVM source as per VMMaker.oscog-eem.2760 ThreadedFFIPlugin: Include the version info in the module name. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/cedc9cdd5769...eb… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/69874125… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[OpenSmalltalk/opensmalltalk-vm] eb087c: CogVM source as per VMMaker.oscog-eem.2760
by Eliot Miranda 16 Jun '20

16 Jun '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: eb087cf5610c6ce61de956278d7711ca2f1a205a https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/eb087cf5610c6ce61d… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-06-15 (Mon, 15 Jun 2020) Changed paths: M src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c M src/plugins/SqueakFFIPrims/ARM64FFIPlugin.c M src/plugins/SqueakFFIPrims/IA32FFIPlugin.c M src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c M src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2760 ThreadedFFIPlugin: Include the version info in the module name.

1 0

VM Maker: VMMaker.oscog-eem.2760.mcz
by commits＠source.squeak.org 16 Jun '20

16 Jun '20

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2760.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2760 Author: eem Time: 15 June 2020, 4:41:45.142399 pm UUID: af828f7f-26c7-4016-9cf1-6175d46e5ab4 Ancestors: VMMaker.oscog-eem.2759 ThreadedFFIPlugin: Include the version info in the module name. Fix a speeling rorre =============== Diff against VMMaker.oscog-eem.2759 =============== Item was changed: ----- Method: CogARMCompiler>>leafCallStackPointerDelta (in category 'abi') ----- leafCallStackPointerDelta "Answer the delta from the stack pointer after a call to the stack pointer immediately prior to the call. This is used to compute the stack pointer + immediately prior to a call from within a leaf routine, which in turn is used - immediately prior to call from within a leaf routine, which in turn is used to capture the c stack pointer to use in trampolines back into the C run-time." "This might actually be false, since directly after a call, lr, fp and variable registers need be pushed onto the stack. It depends on the implementation of call." ^0! Item was changed: ----- Method: CogIA32Compiler>>leafCallStackPointerDelta (in category 'abi') ----- leafCallStackPointerDelta "Answer the delta from the stack pointer after a call to the stack pointer immediately prior to the call. This is used to compute the stack pointer + immediately prior to a call from within a leaf routine, which in turn is used - immediately prior to call from within a leaf routine, which in turn is used to capture the c stack pointer to use in trampolines back into the C run-time." ^4! Item was changed: ----- Method: CogMIPSELCompiler>>leafCallStackPointerDelta (in category 'abi') ----- leafCallStackPointerDelta "Answer the delta from the stack pointer after a call to the stack pointer immediately prior to the call. This is used to compute the stack pointer + immediately prior to a call from within a leaf routine, which in turn is used - immediately prior to call from within a leaf routine, which in turn is used to capture the c stack pointer to use in trampolines back into the C run-time." "This might actually be false, since directly after a call, lr, fp and variable registers need be pushed onto the stack. It depends on the implementation of call." ^0! Item was changed: ----- Method: CogX64Compiler>>leafCallStackPointerDelta (in category 'abi') ----- leafCallStackPointerDelta "Answer the delta from the stack pointer after a call to the stack pointer immediately prior to the call. This is used to compute the stack pointer + immediately prior to a call from within a leaf routine, which in turn is used - immediately prior to call from within a leaf routine, which in turn is used to capture the c stack pointer to use in trampolines back into the C run-time." ^8! Item was changed: InterpreterPlugin subclass: #ThreadedFFIPlugin instanceVariableNames: 'ffiLogEnabled externalFunctionInstSize ffiLastError allocationMap' + classVariableNames: 'DefaultMaxStackSize ExternalFunctionAddressIndex ExternalFunctionArgTypesIndex ExternalFunctionFlagsIndex ExternalFunctionStackSizeIndex MaxNumArgs PluginVersionInfo' - classVariableNames: 'DefaultMaxStackSize ExternalFunctionAddressIndex ExternalFunctionArgTypesIndex ExternalFunctionFlagsIndex ExternalFunctionStackSizeIndex MaxNumArgs' poolDictionaries: 'FFIConstants' category: 'VMMaker-Plugins-FFI'! !ThreadedFFIPlugin commentStamp: 'eem 2/6/2019 16:40' prior: 0! This plugin provides access to foreign function interfaces on those platforms that provide such. For example Windows DLLs and unix .so's. This version is designed to support reentrancy and threading, and so uses alloca to stack allocate all memory needed for a given callout. Specific platforms are implemented by concrete subclasses. Threaded calls can only be provided within the context of the threaded VM; othewise calls must be blocking. So code specific to threading is guarded with a self cppIf: COGMTVM ifTrue: [...] form to arrange that it is only compiled in the threaded VM context. The callout primitives consume a type spec that defines the signature of the function to be called and a vector of arguments. The type spec may be extracted from the method containing an FFI pragma or as an explicit parameter. The arguments to be passed may either be arguments to the the method containing an FFI pragma or as an explicit Array of parameters. Space is allocated to house the marshalled parameters and the type spec and arguments are then parsed to marshall the actual parameters into that space. The space is some combination of alloca'ed (stack allocated) memory for parameters passed on the stack and a "callout state" struct (an instance of ThreadedFFICalloutState) to hold any parameters to be passed in registers. By using C's facilities appropriately we can arrange that the C compiler generates code for passing all parameters, avoiding having to descend to the assembler or machine-code level (*). The basic scheme is to use alloca to stack allocate space for passing stacked parameters, since the memory allocated by alloca is at top-of-stack and in exactly the right place for parameter passing (*), and to invoke the function to be called with as many arguments as there are integer register parameters in the calling convention. For example, on x86/IA32 there are no register parameters and all arguments are passed on the stack, while on ARMv4/5/6 there are four integer register parameters. Since float results are typically answered through a floating-point register and integer/pointer results answered through one (or, on 32-bits for 64-bit results, two) register(s). So on x86 the function to be called is invoked using floatRet := self dispatchFunctionPointer: (self cCoerceSimple: procAddr to: 'double (*)()') or intRet := self dispatchFunctionPointer: (self cCoerceSimple: procAddr to: 'usqLong (*)()') On ARMv4/5/6 it is invoked with floatRet := self dispatchFunctionPointer: (self cCoerceSimple: procAddr to: 'float (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t)') with: (calloutState integerRegisters at: 0) with: (calloutState integerRegisters at: 1) with: (calloutState integerRegisters at: 2) with: (calloutState integerRegisters at: 3) or floatRet := self dispatchFunctionPointer: (self cCoerceSimple: procAddr to: 'double (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t)') with: (calloutState integerRegisters at: 0) with: (calloutState integerRegisters at: 1) with: (calloutState integerRegisters at: 2) with: (calloutState integerRegisters at: 3) or intRet := self dispatchFunctionPointer: (self cCoerceSimple: procAddr to: 'usqIntptr_t (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t)') with: (calloutState integerRegisters at: 0) with: (calloutState integerRegisters at: 1) with: (calloutState integerRegisters at: 2) with: (calloutState integerRegisters at: 3) Hence the C compiler generates the code to pass register parameters appropriately. All we have to do is provide sufficient register parameters and give the function (pointer) to be called a suitable type. Likewise we also persuade the C compiler to generate code to load any floating-point register arguments by preceding any call of a function that takes floating-point arguments passed in registers with a call to loadFloatRegs with as many floating-point parameters as there are floating-point parameter registers. loadFloatRegs is implemented in platforms//Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c as an empty function. So floating-point registers are passed via calls such as: calloutState floatRegisterIndex > 0 ifTrue: [self loadFloatRegs: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 0)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 2)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 4)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 6)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 8)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 10)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 12)) to: #'double *') at: 0) _: ((self cCoerceSimple: (self addressOf: (calloutState floatRegisters at: 14)) to: #'double *') at: 0) (*) some implementations of alloca do not answer the actual top-of-stack, but may answer an address a word or two away. On these implementations we merely derive the top-of-stack instead of using the result of alloca, or perhaps set the stack pointer to the result of alloca, as befits the platform. Callbacks are not handled by this plugin. Instead they are handled by image-level code to create Alien "thunks", small sequences of machine code, that invoke a function thunkEntry, implemented as required by each platform in one of the files in platforms/Cross/plugins/IA32ABI (a regrettable name; it should be something like platforms/Cross/plugins/AlienCallbacks). Each platform's thunkEntry has a signature that takes all integer register parameters (if any), all floating-point register parameters (if any), a pointer to the thunk, and the stack pointer at the point the thunk was invoiked. To pass a callback to foreign code, the marshaller in this plugin passes the address of the thunk. When external code calls that address the think is invoked, and it invokes thunkEntry as required. thunkEntry then saves its parameters locally in an instance of VMCallbackContext, which includes a jmpbuf. thunkEntry then does a setjmp and enters the VM via sendInvokeCallbackContext[:], which cr eates an activation of invokeCallbackContext: to execute the callback. This method then extracts the address of the thunk from the VMCallbackContext and invokes machinery in Callback to match the address with a Smalltalk block. The block is then evaluated with the parameters extracted from the VMCallbackContext, marshalled by methods in Callback subclasses signatures protocol, which know whether a parameter would be passed in a register or on the stack. The result of the block is then passed back to thunkEntry by storing it in a field in the VMCallbackContext and invoking primSignal:andReturnAs:fromContext:, which uses longjmp to jump back to thunkEntry which then extracts the result from its VMCallbackContext and returns. For example, the signature of thunkEntry on x86/IA32 (platforms/Cross/plugins/IA32ABI/ia32abicc.c) is long thunkEntry(void *thunkp, sqIntptr_t *stackp) whereas on ARMv4/5/6 (platforms/Cross/plugins/IA32ABI/arm32abicc.c) it is long long thunkEntry(long r0, long r1, long r2, long r3, double d0, double d1, double d2, double d3, double d4, double d5, double d6, double d7, void *thunkpPlus16, sqIntptr_t *stackp)! Item was changed: ----- Method: ThreadedFFIPlugin class>>initialize (in category 'class initialization') ----- initialize "c.f. ExternalFunction allInstVarNames old: #('handle' 'flags' 'argTypes') new: #('handle' 'flags' 'argTypes' 'stackSize')" ExternalFunctionAddressIndex := 0. ExternalFunctionFlagsIndex := 1. ExternalFunctionArgTypesIndex := 2. ExternalFunctionStackSizeIndex := 3. "c.f. e.g. CoInterpreter class initializeMiscConstants" MaxNumArgs := 15. + DefaultMaxStackSize := 1024 * 16. + + PluginVersionInfo := CCodeGenerator shortMonticelloDescriptionForClass: self. + PluginVersionInfo := PluginVersionInfo allButFirst: (PluginVersionInfo indexOf: Character space) - 1! - DefaultMaxStackSize := 1024 * 16! Item was changed: ----- Method: ThreadedFFIPlugin>>getModuleName (in category 'initialize') ----- getModuleName "Note: This is hardcoded so it can be run from Squeak. The module name is used for validating a module *after* it is loaded to check if it does really contain the module we're thinking it contains. This is important!!" <returnTypeC: 'const char *'> <export: true> + ^'SqueakFFIPrims', PluginVersionInfo! - ^'SqueakFFIPrims'!

1 0

FFI Plugin | Auto-conversion of char* return value into String considered harmful
by Marcel Taeumel 14 Jun '20

14 Jun '20

Hi all! The FFI plugin automatically converts "char*" return values into a Smalltalk string when returning from the FFI call. I would rather leave this conversion to the image side because you have to do it anyway when interpreting external structures. See ExternalData >> #fromCString. And because it can be dangerous. Note that I do like automatic String-to-char* conversion when making an FFI call. Just not the other way around. See (Threaded)FFIPlugin >> #ffiReturnCStringFrom:. What are your thoughts on this matter? Best, Marcel

5 8

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2020