mechglue loading issue

[Tom Yu]

Luke Howard <lukeh at padl.com> writes:

> The mechglue has API-as-SPI, that is, it supports dynamically loading a mechanism that exports the same ABI as the mechanism glue itself (with some exceptions, which are mostly historical or otherwise my doing!).
>
> On the platform I tested, the mechanism glue will pull in the symbol of the glue itself if a mechanism which links against the glue does not implement an entry point.
>
> This of course is catastrophic because mechanism-specific objects will be passed to the glue functions.

That is not the intended behavior...

> I resolved this by passing RTLD_FIRST (fix is in the users/lhoward/moonshot-mechglue-fixes branch). I don't know if this is an OS X-specific issue or not; I guess it could also be resolved by not having the plug-in mechanism link against the mechanism glue, or by having mechanisms implement all entry points (impractical).

As I recall, we use RTLD_GROUP (on Solaris etc.) to force symbol
resolution to look only in objects that are "downstream" of the
dynamically loaded module.  (This adds the requirement that modules
explicitly declare dependencies on everything they need symbols from,
including libc.)  RTLD_GROUP either doesn't work or isn't implemented
on Linux; I'm not sure about the case of Mac OS X.

My impression was that dlsym() would only search the loaded module and
its dependencies for the symbol, not anything else, and that the
RTLD_GROUP controls where the runtime linker resolves the undefined
symbols of the loaded module.

Your need for using RTLD_FIRST implies that the mechanism module has a
dependency on the mechglue, which you imply is the case.  Why is this
necessary?