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

Jean Lee <[email protected]>
Newsgroups gmane.comp.lib.uclibc.general
Message-ID <CALuKrvCLtvnu+NBUv-FiLYOBsFF_yCNHfN8A354uAYs0LqXGtA@mail.gmail.com>
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 <[email protected]>:

> > 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.