Hi,

When implementing the struct __send changes in Jolt code (notably
boot.k), I've found that I need some more of the members of _libid
than just dlsym.

I noticed that function/jolt-burg/Compiler.st exports dlsym,
RTLD_DEFAULT, RTLD_LAZY, RTLD_NOW, and RTLD_GLOBAL.  In the interest
of minimalism, may I suggest that we only export _libid, then use
manifest constants to access the members of it:

(define __dlsym (lambda (symbol) ((long@ _libid 1) symbol)))

This gives us the advantage of late-binding the _libid members, as
above.

To eliminate the platform-dependent RTLD_* constants, and allow
platform-independent manifest constants, I'd suggest we use thin
wrappers instead of dlopen/dlsym directly:

enum __dlopen_mode
{
  DLOPEN_MODE_LAZY = (1 << 31),
  DLOPEN_MODE_NOW = (1 << 30),
  DLOPEN_MODE_GLOBAL = (1 << 29),
};

#define DLHANDLE_DEFAULT ((dlhandle_t) 0)

struct __libid
{
  /* bootstrap */

  dlhandle_t     (*dlopen )(const char *path, int dlopen_mode);
  void          *(*dlsym  )(dlhandle_t handle, const char *symbol);
[...]

and in libid.c:

dlhandle_t dlopen_wrapper(const char *path, int dlopen_mode)
{
  int mode= 0;
  if ((dlopen_mode & DLOPEN_MODE_LAZY) != 0) {
    mode |= RTLD_LAZY;
  }
  if ((dlopen_mode & DLOPEN_MODE_NOW) != 0) {
    mode |= RTLD_NOW;
  }
  if ((dlopen_mode & DLOPEN_MODE_GLOBAL) != 0) {
    mode |= RTLD_GLOBAL;
  }
  return dlopen(path, mode);
}

void *dlsym_wrapper(dlhandle_t handle, const char *symbol)
{
  if (handle == DLHANDLE_DEFAULT) {
    handle = RTLD_DEFAULT;
  }
  return dlsym(handle, symbol);
}

Why the manifest constants?  I imagine that right now _libid is much
like a kernel syscall interface.  We need to be able to depend on its
layout as part of the ABI, since Jolt doesn't yet understand C.  Once
Coke materialises, we'll be able to decouple the _libid layout from
its users, and Coke will be able to do
_libid->dlopen("something", DLOPEN_MODE_NOW | etc).

Let me know what you think,

-- 
Michael FIG <[EMAIL PROTECTED]> //\
   http://michael.fig.org/    \//

_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to