dlopen() behaving weird

[David Given]

(Originally posted to -developers, but this seems to be more of an
-internals issue so reposting here. Slightly modifying for clarity.)

I'm trying to use JNI to load a library. However, I seem to have a
situation where System.loadLibrary() --- which I assume is calling
dlopen() behind the scenes --- is incorrectly applying relocations in
shared libraries. Here's some sample code:

---snip---
struct foo { int first, second };
struct foo Foo = {1, 2};

int* FooPtr[] = { &Foo.first, &Foo.second };

JNIEXPORT jint JNICALL Java_com_cowlark_CTest1
(JNIEnv* jenv, jclass clazz)
{
return *FooPtr[0];
}

JNIEXPORT jint JNICALL Java_com_cowlark_CTest2
(JNIEnv* jenv, jclass clazz)
{
return *FooPtr[1];
}
---snip---

When I run this, I'd expect CTest1() and CTest2() to return 1 and 2
respectively (and that's what I get if I plug it into a test harness on
the host). What I actually *get* is 1 and 1.

The linker produces (and I've verified manually that this is correct!)
the following relocation data for FooPtr:

00000000 00005102 R_ARM_ABS32 00000000 Foo
00000004 00005102 R_ARM_ABS32 00000000 Foo

This means 'add the address of Foo to the thing at offset 0 in the
.data.rel section' (twice). (FooPtr is at offset 0.) Since before
relocation the FooPtr array contains the offset from Foo of the
resulting address, that is, 0 and 4 respectively, once the relocation is
complete FooPtr will contain Foo+0 and Foo+4.

What I actually end up with if Foo+0 and Foo+0. That is, it appears to
be incorrectly discarding the offset.

I'm building this with the CodeSourcery arm-none-linux-gnueabi toolchain
using the custom .xsc file as described here:

http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-android.html

The linker command I'm using is:

arm-none-linux-gnueabi-ld -g -Os -fPIC --dynamic-linker
/system/bin/linker -nostdlib -rpath /system/lib -shared
-Tarmelf_linux_eabi.xsc -o obj/libFnord.so ...o files here...

Am I missing anything, or is there something wrong with dlopen()? I
can't *imagine* that if there were, someone wouldn't have stumbled over
it by now...

--
David Given
d...@cowlark.com

[David Given]

David Given wrote:
[...]

> I'm trying to use JNI to load a library. However, I seem to have a
> situation where System.loadLibrary() --- which I assume is calling
> dlopen() behind the scenes --- is incorrectly applying relocations in
> shared libraries.

[...]

I'm sorry to keep hassling everyone, but does *anyone* know anything
about this? Even if it's as simple as, 'I agree, that looks odd, submit
a bug report' or 'We need more information, can you show us X, Y and Z'?

Currently this is causing my app to be completely dead in the water:
we're using this construction heavily in the C side of things for tables
of function pointers, and right now it's calling all the wrong functions.

I'm *hoping* that it's something simple I'm doing wrong in the link
phase, because then I can fix it pretty straightforwardly; but I can't
think what...

--
David Given
d...@cowlark.com

[Diluka Moratuwage]

I also experienced the same thing. Not only dlopen() but there may be
many functions that will not be working. No documentation about those
things yet. Really you will be wasting your time on using the C
libraries in Android and experimenting using them. I recommend you to
stay some time and continue native development when the documentation is
available. I also tried really hard on few things and now waiting to see
until some more information is available about the C library facilities
available in Android.

Thanks,
Diluka.

[David Given]

Diluka Moratuwage wrote:
[...]

> Not only dlopen() but there may be
> many functions that will not be working. No documentation about those
> things yet. Really you will be wasting your time on using the C
> libraries in Android and experimenting using them.

Well, having spent *far* too much time working on unsupported platforms
with buggy development boards, half-finished operating systems,
inaccurate documentation and bad design, I'm generally quite happy with
working on my own based on reverse engineering and software archaeology.

However, right now I don't know whether this issue --- which is blocking
our app from working completely --- is my fault or a more serious bug.
If it's my fault, that's fine. If it's a bug, however, it needs an
official bug report so it doesn't get forgotten about and to make sure
it gets fixed somewhere down the line. But I can't file a bug report
until I know whether it's a bug or not!

--
David Given
d...@cowlark.com

[Diluka Moratuwage]

I suggest you to use "strace" program, and going through the output with
regard to dlopen(), I'm sure it will give some idea of how Android does
that. But I'm not sure whether it's what you really want.
f
Thanks,
Diluka.

[Diluka Moratuwage]

I suggest you to use "strace" program, and going through the output with
regard to dlopen(), I'm sure it will give some idea of how Android does
that. But I'm not sure whether it's what you really want.

Thanks,
Diluka.

[David Given]

Diluka Moratuwage wrote:
> I suggest you to use "strace" program, and going through the output with
> regard to dlopen(), I'm sure it will give some idea of how Android does
> that. But I'm not sure whether it's what you really want.

Actually, Digit confirmed on -developers that this is, indeed, a dynamic
loader bug. (They don't see it because of the shared library prelinking
they do. Unfortunately, the prelinker isn't available yet...)

It's now #599 on the bug tracker.

I have a workaround that will hopefully keep me going until the fix
comes out.

--
David Given
d...@cowlark.com