[PATCH]mips: ldso: dlopen with flag RTLD_NOW should look up the symbols

Jean Lee xiaoyur347 at gmail.com
Sat Feb 21 12:09:43 UTC 2015


Andrew, thanks for your reply. You are a mips engineer~
I have a following example for dlopen problem, which I tested a few days
ago, but I have no mips environment these days. Would you mind to test it
for me. Many thanks.

Example:
File main.cpp
#include <stdio.h>
#include <dlfcn.h>

typedef void (*init_function_t)(void);

int main()
{
#ifndef __mips__
const char *strLibName = "./libtest_x86.so";
#else
const char *strLibName = "./libtest_mips.so";
#endif
void *pHandle = dlopen(strLibName, RTLD_NOW);
if (pHandle == NULL)
{
printf("open %s fail. %s\n", strLibName, dlerror());
return 1;
}
init_function_t pFunc = (init_function_t)dlsym(pHandle, "init");
if (pFunc == NULL)
{
printf("libtest.so has no init function\n");
dlclose(pHandle);
return 2;
}
pFunc();
dlclose(pHandle);
return 0;
}

File libtest.cpp
extern "C" {
extern void not_exist_function(void);
extern void init(void)
{
not_exist_function();
}

} // extern "C"

File build.sh, run build.sh to get the library and the executable.
#!/bin/sh
g++ -shared -fPIC libtest.cpp -o libtest_x86.so
g++ main.cpp -o x86_test -ldl
mipsel-linux-g++ -shared -fPIC libtest.cpp -o libtest_mips.so
mipsel-linux-g++ main.cpp -o mips_test -ldl

Since I have no mips environment these days, I can only run the x86
environment(./x86_test)
And get the following result for x86
open ./libtest_x86.so fail. ./libtest_x86.so: undefined symbol:
not_exist_function

But in mips environment(./mips_test), the unexpected result is
"Segment Fault"
Which is expected to
open ./libtest_x86.so fail.File not found

2015-02-20 20:59 GMT+08:00 Andrew Bennett <Andrew.Bennett at imgtec.com>:

> > Reason:
> > MIPS ELF strategy is so different from other architectures like x86 and
> arm.
> > When fPIC enabled in x86 and arm, ".rel.plt" section is generated after
> > ".rel.dyn" section, and the dependency of the library (like the function
> and
> > object) . But MIPS only generates ".rel.dyn" section for the library when
> > fPIC, and ".rel.dyn" section can only be generated in non-PIC executable.
> > This leads to a bug which other architectures will not have.
> >
> > Description:
> > If you dlopen a library, uclibc only check the symbols defined in
> ".rel.dyn"
> > section. And ".rel.dyn" section has no outer dependency, most flags have
> the
> > type "R_MIPS_REL32". Only ".rel.plt" section generates call to
> > R_MIPS_JUMP_SLOT and R_MIPS_COPY.
> > In my environment, I almost see the cplusplus virtual functions in
> ".rel.dyn".
> >
> > Bug Demo:
> > use mipsel-linux-readelf -aW libxx.so to view the dependency.
> >
> > Patch:
> > MIPS: Scan the symtab for the dependency of the library to avoid runtime
> empty
> > function pointer.
> > The dependency = SHN_UNDEF && STB_GLOBAL && (STT_FUNC || STT_OBJECT)
>
> Hi Jean,
>
> I am a little unclear why this patch is required.  Could you provide me
> with a
> more detailed explanation, and a testcase/example showing the problem?
>
> Many thanks,
>
>
> Andrew
>


More information about the uClibc mailing list