Errored: OpenSmalltalk/opensmalltalk-vm#1930 (Cog - 5aede68)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Errored: OpenSmalltalk/opensmalltalk-vm#1930 (Cog - 5aede68)

Travis CI
 

OpenSmalltalk

/

opensmalltalk-vm

branch iconCog

arrow to build time
clock icon2 hrs, 10 mins, and 10 secs

Eliot Miranda avatarEliot Miranda

CogVM source as per VMMaker.oscog-nice.2680/VMMaker.oscog-eem.2685.

ThreradedFFIPlugin: solve passing/returning struct by value on X64

See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/443

On X64/SysV struct up to 16 byte long can be passed by value (& returned) into
a pair of 8-byte registers. The problem is to know whether these are integer
(RAX RDX) or float (XMM0 XMM1) registers or eventually a mix of...

For each 8-byte, we must know if it contains at least an int (in which case we
have to use an int register), or exclusively floating points (a pair of float
or a double). Previous algorithm did check first two fields, or last two fields
which does not correctly cover all cases... For example int-int-float has last
two fields int-float, though it will use RAX XMM0.

So we have to know about struct layout... Unfortunately, this information is
not included into the compiledSpec.
The idea here is to reconstruct the information.
See #registerTypeForStructSpecs:OfLength: &

It's also impossible to cover the exotic alignments like packed structure
cases... if we really want to pass that, this will mean passing the alignment
information, a more involved change of #compiledSpec (we need up to 16 bits by
field to handle that information since our FFI struct are limited to 65535
bytes anyway).

For returning a struct, that's the same problem.
We have four possible combinations of int-float registers.
Consequently, the idea is to analyze #registerType: and switch to appropriate
case. I found convenient to pass the ffiRetSpec compiledSpec object thru
CalloutState (it's the Smalltalk WordArray object, not a pointer to its
firstIndexableField) for performing this analysis... Not sure if this is the
best choice.

Since we have 4 different SixteenByte types, I have changed
value, since it's what will be used to memcpy to allocated ByteArray handle.

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you!

SIGN UP HERE
book icon

Documentation about Travis CI

<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "EmailMessage", "action": { "@type": "ViewAction", "url": "https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/643487143?utm_medium=notification&amp;utm_source=email", "name": "View Build" }, "description": "View Build #1930 on Travis CI" } </script>