[vmkit-commits] [PATCH] Fix symbol search order to fix detection of symbols from vmkit or loaded libs

[Will Dietz]

On Tue, Nov 15, 2011 at 2:41 PM, Will Dietz <wdietz2 at illinois.edu> wrote:
> On Tue, Nov 15, 2011 at 2:24 PM, Nicolas Geoffray
> <nicolas.geoffray at gmail.com> wrote:
>> Hi Will,
>>
>> I'm not sure that's right. With GNU Classpath, I also want to define my own
>> methods and not use the ones implemented in Classpath. If we reorder things,
>> the method defined in GNU Classpath will be used. Not mine.
>> vmkit is using RTLD_LOCAL when loading, so symbol resolution on a dlsym must
>> provide the loaded library. If you do dlsym(SELF_HANDLE, 'mysymbol'), you'll
>> only get symbols loaded in the j3 executable.
>> What is it that does not work for you?
>> Cheers,
>> Nicolas
>>
>

Hmm, you're right that regardless of my discussion below, this changes
the behavior for symbols that are defined in both places.

Unfortunately, it appears that OpenJDK likes to dlopen() with
RTLD_GLOBAL, which complicates things.

> Hmm.
>
> Well, to answer your question I'm seeing the 'j3' flag set for things
> like Java_awt_Font_initIDs, resulting in calling the functions wrong.
>
> As for whether or not it's correct: I'm not sure that
> dlsym(RTLD_DEFAULT,...) is the same as dlsym(dlopen(NULL),...), which
> might be the difference.  The latter clearly does what you suggest,
> the former I'm not sure (from the man pages).
>

Nope, I'm just wrong here.  Sure seems to be identical in the cases I
put together, my mistake :).

So this leaves us with "what to do?".

One idea is we manually maintain the set of symbols that we want to
override, and teach vmkit to handle them appropriately.  I believe
this is what was done earlier.

Alternatively we could check what symbols we define and incorporate
those when building a tool.  Build a special file that contains an
array of the symbols defined in the tool's dependent libraries and
link the result in to the final tool.  Bit messy, but would work well
with what we already have.

(I'm ignoring having vmkit scan itself on startup since that seems
detrimental to startup times)

Finally, and I think this is ruled out due to some GC issue (right?),
but we could put all the methods we override in a special
"libOverride.so/dylib" (with a better name) and use an explicit handle
to that library to achieve the desired result.

Thoughts?

~Will