Nicolas Cellier uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog- nice.2366.mcz
==================== Summary ====================
Name: VMMaker.oscog- nice.2366
Author: nice
Time: 17 April 2018, 3:37:48.684079 pm
UUID: 6d9bd2fa-c381-5d4b-b31e-c6d21225c848
Ancestors: VMMaker.oscog-VB.2365
Correct a 32bit-hardcoded pointer size in FFI
Correct two copy/paste typos in num32BitUnitsOf:
Note: I don't like the FFI code that I just corrected. IMO, it does the wrong thing.
if I have an argument spec is
MyLib>>foo: aFoo
<cdecl: void foo(Foo *)>
where Foo is some ExternalStructure subclass (Foo class>>fields ^#((x 'ushort') (y 'ushort')))
and that I try to pass (MyLib new foo: Foo new), it seems to me that the Foo new getHandle will be (ByteArray new: 4).
What I understand form the code that I just corrected is that we are trying to pass the contents of the ByteArray re-interpreted as a void pointer. Scary and wrong...
If I instead pass (MyLib new foo: Foo externalNew), it seems that we don't even bother to check if the (argSpec anyMask: FFIFlagPointer) and just force passing the structure by value (thru a memcpy on stack). Scary and wrong...
In general, every one use <cdecl: void foo(void *)> to work around this ill-behavior, and thus bypass type checks...
Also note that we can't even pass an ExternalData (think an Array of Foo), because ffiArgument:Spec:Class:in: insists on having actualArg class inheritsFrom: argType referentClass. ExternalData does not inherit from Foo, event if its type matches (ExternalType structTypeNamed: #Foo). That's crazy...
Another reason while people use <cdecl: void foo(void *)>
It's high time to consider a rewrite IMO.
=============== Diff against VMMaker.oscog-VB.2365 ===============
Item was changed:
----- Method: ObjectMemory>>num32BitUnitsOf: (in category 'object access') -----
num32BitUnitsOf: objOop
+ "Answer the number of 32-bit units in the given non-immediate object.
- "Answer the number of 16-bit units in the given non-immediate object.
N..B. Rounds down 8-bit units, so a 7 byte object has 1 32-bit unit.
Does not adjust the size of contexts by stackPointer."
^(self numBytesOf: objOop) >> 2!
Item was changed:
----- Method: SpurMemoryManager>>num32BitUnitsOf: (in category 'object access') -----
num32BitUnitsOf: objOop
+ "Answer the number of 32-bit units in the given non-immediate object.
- "Answer the number of 16-bit units in the given non-immediate object.
N..B. Rounds down 8-bit units, so a 7 byte object has 1 32-bit unit.
Does not adjust the size of contexts by stackPointer."
^(self numBytesOf: objOop) >> 2!
Item was changed:
----- Method: ThreadedFFIPlugin>>ffiPushStructureContentsOf:in: (in category 'callout support') -----
ffiPushStructureContentsOf: oop in: calloutState
<var: #calloutState type: #'CalloutState *'>
"Push the contents of the given external structure"
| ptrClass ptrAddress |
<inline: true>
ptrClass := interpreterProxy fetchClassOf: oop.
ptrClass = interpreterProxy classExternalAddress ifTrue: "ExternalAddress is bytes"
[ptrAddress := (interpreterProxy fetchPointer: 0 ofObject: oop) asVoidPointer.
"There is no way we can make sure the structure is valid.
But we can at least check for attempts to pass pointers to ST memory."
(interpreterProxy isInMemory: ptrAddress) ifTrue:
[^FFIErrorInvalidPointer].
^self ffiPushStructure: ptrAddress
ofSize: (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
typeSpec: calloutState ffiArgSpec
ofLength: calloutState ffiArgSpecSize
in: calloutState].
ptrClass = interpreterProxy classByteArray ifTrue:
["The following is a somewhat pessimistic test but I like being sure..."
(interpreterProxy byteSizeOf: oop) = (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
ifFalse:[^FFIErrorStructSize].
ptrAddress := interpreterProxy firstIndexableField: oop.
(calloutState ffiArgHeader anyMask: FFIFlagPointer) ifFalse:
"Since this involves passing the address of the first indexable field we need to fail
the call if it is threaded and the object is young, since it may move during the call."
[self cppIf: COGMTVM ifTrue:
[((calloutState callFlags anyMask: FFICallFlagThreaded)
and: [interpreterProxy isYoung: oop]) ifTrue:
[^PrimErrObjectMayMove negated]].
^self ffiPushStructure: ptrAddress
ofSize: (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
typeSpec: calloutState ffiArgSpec
ofLength: calloutState ffiArgSpecSize
in: calloutState].
"If FFIFlagPointer + FFIFlagStructure is set use ffiPushPointer on the contents"
+ (calloutState ffiArgHeader bitAnd: FFIStructSizeMask) = BytesPerWord ifFalse:
- (calloutState ffiArgHeader bitAnd: FFIStructSizeMask) = 4 ifFalse:
[^FFIErrorStructSize].
ptrAddress := (interpreterProxy fetchPointer: 0 ofObject: oop) asVoidPointer.
(interpreterProxy isInMemory: ptrAddress) ifTrue:
[^FFIErrorInvalidPointer].
^self ffiPushPointer: ptrAddress in: calloutState].
^FFIErrorBadArg!
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog- nice.2366.mcz
==================== Summary ====================
Name: VMMaker.oscog- nice.2366
Author: nice
Time: 17 April 2018, 3:37:48.684079 pm
UUID: 6d9bd2fa-c381-5d4b-b31e-c6d21225c848
Ancestors: VMMaker.oscog-VB.2365
Correct a 32bit-hardcoded pointer size in FFI
Correct two copy/paste typos in num32BitUnitsOf:
Note: I don't like the FFI code that I just corrected. IMO, it does the wrong thing.
if I have an argument spec is
MyLib>>foo: aFoo
<cdecl: void foo(Foo *)>
where Foo is some ExternalStructure subclass (Foo class>>fields ^#((x 'ushort') (y 'ushort')))
and that I try to pass (MyLib new foo: Foo new), it seems to me that the Foo new getHandle will be (ByteArray new: 4).
What I understand form the code that I just corrected is that we are trying to pass the contents of the ByteArray re-interpreted as a void pointer. Scary and wrong...
If I instead pass (MyLib new foo: Foo externalNew), it seems that we don't even bother to check if the (argSpec anyMask: FFIFlagPointer) and just force passing the structure by value (thru a memcpy on stack). Scary and wrong...
In general, every one use <cdecl: void foo(void *)> to work around this ill-behavior, and thus bypass type checks...
Also note that we can't even pass an ExternalData (think an Array of Foo), because ffiArgument:Spec:Class:in: insists on having actualArg class inheritsFrom: argType referentClass. ExternalData does not inherit from Foo, event if its type matches (ExternalType structTypeNamed: #Foo). That's crazy...
Another reason while people use <cdecl: void foo(void *)>
It's high time to consider a rewrite IMO.
=============== Diff against VMMaker.oscog-VB.2365 ===============
Item was changed:
----- Method: ObjectMemory>>num32BitUnitsOf: (in category 'object access') -----
num32BitUnitsOf: objOop
+ "Answer the number of 32-bit units in the given non-immediate object.
- "Answer the number of 16-bit units in the given non-immediate object.
N..B. Rounds down 8-bit units, so a 7 byte object has 1 32-bit unit.
Does not adjust the size of contexts by stackPointer."
^(self numBytesOf: objOop) >> 2!
Item was changed:
----- Method: SpurMemoryManager>>num32BitUnitsOf: (in category 'object access') -----
num32BitUnitsOf: objOop
+ "Answer the number of 32-bit units in the given non-immediate object.
- "Answer the number of 16-bit units in the given non-immediate object.
N..B. Rounds down 8-bit units, so a 7 byte object has 1 32-bit unit.
Does not adjust the size of contexts by stackPointer."
^(self numBytesOf: objOop) >> 2!
Item was changed:
----- Method: ThreadedFFIPlugin>>ffiPushStructureContentsOf:in: (in category 'callout support') -----
ffiPushStructureContentsOf: oop in: calloutState
<var: #calloutState type: #'CalloutState *'>
"Push the contents of the given external structure"
| ptrClass ptrAddress |
<inline: true>
ptrClass := interpreterProxy fetchClassOf: oop.
ptrClass = interpreterProxy classExternalAddress ifTrue: "ExternalAddress is bytes"
[ptrAddress := (interpreterProxy fetchPointer: 0 ofObject: oop) asVoidPointer.
"There is no way we can make sure the structure is valid.
But we can at least check for attempts to pass pointers to ST memory."
(interpreterProxy isInMemory: ptrAddress) ifTrue:
[^FFIErrorInvalidPointer].
^self ffiPushStructure: ptrAddress
ofSize: (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
typeSpec: calloutState ffiArgSpec
ofLength: calloutState ffiArgSpecSize
in: calloutState].
ptrClass = interpreterProxy classByteArray ifTrue:
["The following is a somewhat pessimistic test but I like being sure..."
(interpreterProxy byteSizeOf: oop) = (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
ifFalse:[^FFIErrorStructSize].
ptrAddress := interpreterProxy firstIndexableField: oop.
(calloutState ffiArgHeader anyMask: FFIFlagPointer) ifFalse:
"Since this involves passing the address of the first indexable field we need to fail
the call if it is threaded and the object is young, since it may move during the call."
[self cppIf: COGMTVM ifTrue:
[((calloutState callFlags anyMask: FFICallFlagThreaded)
and: [interpreterProxy isYoung: oop]) ifTrue:
[^PrimErrObjectMayMove negated]].
^self ffiPushStructure: ptrAddress
ofSize: (calloutState ffiArgHeader bitAnd: FFIStructSizeMask)
typeSpec: calloutState ffiArgSpec
ofLength: calloutState ffiArgSpecSize
in: calloutState].
"If FFIFlagPointer + FFIFlagStructure is set use ffiPushPointer on the contents"
+ (calloutState ffiArgHeader bitAnd: FFIStructSizeMask) = BytesPerWord ifFalse:
- (calloutState ffiArgHeader bitAnd: FFIStructSizeMask) = 4 ifFalse:
[^FFIErrorStructSize].
ptrAddress := (interpreterProxy fetchPointer: 0 ofObject: oop) asVoidPointer.
(interpreterProxy isInMemory: ptrAddress) ifTrue:
[^FFIErrorInvalidPointer].
^self ffiPushPointer: ptrAddress in: calloutState].
^FFIErrorBadArg!
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 2d052c2bea0ea81e611571ee70f66b6cde5d657c
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2d052c2bea0ea81e61…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2018-04-16 (Mon, 16 Apr 2018)
Changed paths:
M build.win32x86/newspeak.cog.spur/nsvm.exe.manifest
M build.win32x86/newspeak.stack.spur/nsvm.exe.manifest
M build.win32x86/pharo.cog.spur.lowcode/Pharo.exe.manifest
M build.win32x86/pharo.cog.spur/Pharo.exe.manifest
M build.win32x86/pharo.sista.spur/Pharo.exe.manifest
M build.win32x86/squeak.cog.spur.lowcode/Croquet.exe.manifest
M build.win32x86/squeak.cog.spur.lowcode/Squeak.exe.manifest
M build.win32x86/squeak.cog.spur/Croquet.exe.manifest
M build.win32x86/squeak.cog.spur/Squeak.exe.manifest
M build.win32x86/squeak.cog.v3/Croquet.exe.manifest
M build.win32x86/squeak.cog.v3/Squeak.exe.manifest
M build.win32x86/squeak.sista.spur/Croquet.exe.manifest
M build.win32x86/squeak.sista.spur/Squeak.exe.manifest
M build.win32x86/squeak.stack.spur/Croquet.exe.manifest
M build.win32x86/squeak.stack.spur/Squeak.exe.manifest
M build.win32x86/squeak.stack.v3/Croquet.exe.manifest
M build.win32x86/squeak.stack.v3/Squeak.exe.manifest
M build.win64x64/newspeak.cog.spur/nsvm.exe.manifest
M build.win64x64/newspeak.stack.spur/nsvm.exe.manifest
M build.win64x64/pharo.cog.spur/Pharo.exe.manifest
M build.win64x64/pharo.stack.spur/Pharo.exe.manifest
M build.win64x64/squeak.cog.spur/Croquet.exe.manifest
M build.win64x64/squeak.cog.spur/Squeak.exe.manifest
M build.win64x64/squeak.stack.spur/Croquet.exe.manifest
M build.win64x64/squeak.stack.spur/Squeak.exe.manifest
Log Message:
-----------
Update the Windows manifest files to refer to opensmalltalk.org; they were still
referring to mirandabanda.org.
Ok thank you!
Here is a link to the mcz:
https://drive.google.com/open?id=1IPHR6JdkXbthqe3ObyVMG7prHAAGvTpg
--
Cyril Ferlicot
https://ferlicot.fr
On sam., avr. 14, 2018 at 04:58, David T. Lewis <lewis(a)mail.msen.com> wrote:
> Hi Cyril, Unfortunately the MCZ attachment to your mail is too large for a mailing list. I am forwarding this back to vm-dev so that your message (below) will be seen. Eliot, others: Perhaps we need an inbox for the VMMaker repository? Or just add Cyril directly to the VMMaker repository? I cannot look at the MCZ file, I am just forwarding this because it was blocked on the mailing list. Dave On Fri, Apr 13, 2018 at 11:11:02PM +0000, vm-dev-owner(a)lists.squeakfoundation.org wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: Vm-dev(a)lists.squeakfoundation.org > From: cyril(a)ferlicot.me > Subject: Contribution to VMMaker > Reason: Message body is too big: 6196344 bytes with a limit of 600 KB > > At your convenience, visit: > > http://lists.squeakfoundation.org/mailman/admindb/vm-dev > > to approve or deny the request. > Date: Fri, 13 Apr 2018 19:10:39 -0400 > To: Squeak Virtual Machine Development Discussion > From: Cyril Ferlicot D > Reply-To: Cyril Ferlicot D > Subject: Contribution to VMMaker > > Hello, > > Yesterday I generated for the first time the C code of the VM after > building the VMMaker image. > > While building I though it would be cool when generating multiple vms to > have more info about the generation progress. Like that it's easier to > know if we have the time to do something else outside the image or not. > > I implemented this on the .mcz joined in this mail. If the change is ok > with you maybe you can either integrate it or give me the rights to > integrate it. > > I created an account on source.squeak.org. Name: CyrilFerlicot > > Have a nice day. > > -- > Cyril Ferlicot > https://ferlicot.fr > @ferlicot.me> @ferlicot.me> @lists.squeakfoundation.org>