[Vm-dev] Call to Unix experts: how i can obtain a pointers to mmap/dlopen/dlsym functions?

Eliot Miranda eliot.miranda at gmail.com
Sat Sep 25 17:17:10 UTC 2010


On Sat, Sep 25, 2010 at 10:10 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 25 September 2010 19:30, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Sat, Sep 25, 2010 at 7:30 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 25 September 2010 10:32, K. K. Subramaniam <kksubbu.ml at gmail.com>
> wrote:
> >> > On Saturday 25 Sep 2010 6:44:19 am Igor Stasenko wrote:
> >> >> But on Linux, mmap() is a part of GLIBC library.
> >> >> Any idea, what module name i could use to get a pointer to
> >> >> mmap/dlopen/dlsym using interpreterProxy functions?
> >> > libc.so.6 (for sixth generation C library). see man page for libc
> >> >
> >> how i can be sure that squeak vm always using this ' sixth generation
> >> C library',
> >> and i'm not trying load a different version of it?
> >> Where the guarantees that all unix boxes using libc.so.6?
> >
> > Nothing.  And on Mac OS X it will likely be libSystem.B.dylib and on
> Solaris will be something else again etc.  You'll need to use the tool that
> displays the dynamic libraries against which the VM is linked.  e.g.
> > ldd cogunix/bin/lib/squeak/3.9-7/squeak
> >         linux-gate.so.1 =>  (0x00765000)
> >         libutil.so.1 => /lib/libutil.so.1 (0x06b55000)
> >         libdl.so.2 => /lib/libdl.so.2 (0x00afd000)
> >         libpthread.so.0 => /lib/libpthread.so.0 (0x00b04000)
> >         libm.so.6 => /lib/libm.so.6 (0x00ad2000)
> >         libnsl.so.1 => /lib/libnsl.so.1 (0x064b5000)
> >         libc.so.6 => /lib/libc.so.6 (0x00b53000)
> >         /lib/ld-linux.so.2 (0x00ab3000)
> >
> >  otool -L Cog/oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet
> > Cog/oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet:
> >
>  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> (compatibility version 150.0.0, current version 476.19.0)
> >         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 136.0.0)
> >         /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
> >         /System/Library/Frameworks/AGL.framework/Versions/A/AGL
> (compatibility version 1.0.0, current version 1.0.0)
> >
>  /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
> (compatibility version 1.0.0, current version 1327.73.0)
> >
>  /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
> (compatibility version 1.0.0, current version 1.0.0)
> >
>  /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
> (compatibility version 1.0.0, current version 1.0.0)
> >         /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
> (compatibility version 1.0.0, current version 275.0.0)
> >
>  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> (compatibility version 300.0.0, current version 677.26.0)
> >
>  /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
> (compatibility version 1.0.0, current version 212.2.0)
> >         /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 949.54.0)
> >         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.4)
> >         /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 227.0.0)
> >
>  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
> (compatibility version 1.0.0, current version 32.0.0)
> >
>  /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
> (compatibility version 1.0.0, current version 34.0.0)
> > It would be convenient if the VM could answer the basename of the C
> library against which it was linked, e.g. through a systemAttributeAt:, but
> I expect that would be implemented by using a manifest string constant in
> the VM.  Clearly this info belongs in the VM, not a table in the image.  But
> VM builders would still need to test it as it could easily get stale if its
> supplied from the build system.  We'd need a test and e.g. one of my Alien
> tests is an invocation of qsort which is in the C library.
>
> Exactly the same. I also using qsort to test callbacks.
> Obviously, its easy to run tool from command line to discover the
> library, and that was the reason why i can't google for solution,
> because all pages it finds, says: hey, just run this tool and you are
> done! Apparently not. I don't wanna tell user, who running
> squeak VM : hey pal, since you on linux, run this tool from command
> line and then copy the library name here and then you done. :)
>
> This is the case, when it is good to have a well-established standarts
> or conventions...
>
> > Igor, for now I would hard code this in the image.  But we should add it
> to the VM soon.
>
> Well, i just added prim which returns a dlsym() function pointer. But
> it would be good if interpreterProxy->ioLoadSymbolOfLengthFromModule()
> could accept a default module handle, which corresponds to process's
> global symbol space.
>

On Unix systems using dlopen et al that's dlsym(RTLD_DEFAULT,symbolname).  I
don't know what the equivalent, if any, there is on Windows.


>
> > But this raises an important issue.  I think the architecture of dynamic
> linking of both named primitives and FFI calls in Squeak is wrong.  The VM
> does all the work of binding names to functions, taking a function name,
> library/plugin pair and resolving it to an address, which means for example
> that one can't substitute a symbolic name such as TheCLibrary in an FFI call
> since this name will be interpreted literally by the VM (and will fail).
> > If instead there were two primitives, openLibrary and lookupInLibrary (as
> there are in Alien) then the linking machinery could be moved up into the
> image where we could concretize symbolic names.  This would be done either
> explicitly, e.g.
> >     myPluginPrimitive
> >         <primitive: 'myPluginPrimitive' module: 'ThePlugin' error:
> errorCode>
> >         errorCode == #unlinked ifTrue:
> >             [^thisContext linkAndRetryExternalPluginInvocation]
> >         ...
> >     qsort: base elements: nel width: width comparator: compar
> > <apicall: void 'qsort' (void* ulong ulong void*)
> > module: 'WhateverTheCLibraryIsOnThisPlatform'
> > error: err>
> >         errorCode == #unlinked ifTrue:
> >             [^thisContext linkAndRetryExternalPluginInvocation]
> > ^self externalCallFailedWith: err
> > or, as it is in VisualWorks, with a hidden callback (selector in the
> specialObjectsArray) that sends a message to the unlinked method whose
> arguments are the calls receiver and arguments.  Personally I think the
> explicit method is better since its more flexible.
>
> Yes. And i trying to add this to NativeBoost, so you can choose own
> way how to search for module and symbol in it.
> But i thought that for bootstrapping NativeBoost itself, i could reuse
> vm functionality to access requred bits (dlsym/dlopen),
> and then i free to do anything else from that point.
>
>
> > best
> > Eliot
> >>
> >> > Subbu
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100925/02669382/attachment.htm


More information about the Vm-dev mailing list