[squeak-dev] Loading FFI is broken

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 20 16:51:51 UTC 2013


On Tue, Nov 19, 2013 at 7:57 PM, Andres Valloud <
avalloud at smalltalk.comcastbiz.net> wrote:

> On 11/19/13 19:13 , Eliot Miranda wrote:
>
>> I would argue that in fact the best way to deal with differing UNIX
>> implementations is this approach.  For example, ioctl defines, socket
>> constant defines, struct layouts, etc, etc all differ markedly between
>> UNIX implementations, and hence one easy way to extract exact
>> information is to generate, compile and either run or load a program
>> that reveals the implementation details.
>>
>
> It's not clear to me how an arbitrary interpretation mechanism


I didn't untroduce an interpretation mechanism, I introduced a compialtion
mechanism.


> would reveal what function to call to invoke e.g. malloc(), assuming
> that's all there is to it.  The mechanism would have to deal with arbitrary
> macro code expansion, arbitrary code without source code provided by the
> compiler itself, and on some platforms such as OS X the behavior of
> malloc() could depend on the value of environment variables at the time the
> binary is loaded (as opposed to the time when the interpretation mechanism
> looks at said variables).  Similarly, it's unclear what that interpretation
> mechanism would do in the general presence of things like
>
> #if defined(FOO)
> ...
> #endif
>
> To me, avoiding writing a few lines of C does not justify the effort of
> correctly rewriting and maintaining (parts of) a C compiler in Smalltalk.
>

No matter what, the following defines a function that takes an integer and
returns the result of malloc:

#include <stdlib.h>
void *malloc_wrapper(int n) { return malloc(n); }

This wrapper can be auto-generated and compiled into a shared object or dll
and used to wrap whatever crap the underlying platform chooses to use in
implementing malloc.

This can also be used to wrap macros and print the values of simple defines.

A similar approach can be used to derive the layouts of things like a
struct stat.

#define printfield(s,f) printf("&" #s "." #f "=%ld\n", offsetof(s.f))

So one can use the C compiler to extract layout information easily that
abstracts away from implementation detail and means the Smalltalk system
*does not* have to implement a C compiler, merely invoke one.

Note that this approach is a fall-back for perverse platforms.  Most
platforms are not remotely this difficult to use.  Most allow us to
directly call functions, know the layouts of structures and so on.

The above can be autogenerated.


> Generally, I agree that one could carefully and consciously write
> comparatively small primitives and/or plugins.  Then, one could compile
> those with a C compiler in a compilation environment compatible with that
> of the VM.  And then, one could call those primitives and/or plugins from
> the image with the expectation (within reason) that they should work.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/d8d566bb/attachment.htm


More information about the Squeak-dev mailing list