Variable and function access between Linux master files and dynamic libraries

Normally we need to invoke the functions and variables in the executable program directly from the dynamic library, and if the-l option is called, the Linux process will automatically add the functions and variables of the dynamic library to the dynamic segment, so direct access is no problem.

What we're going to say here is a non-display connection to the dynamic library, instead of opening the dynamic library access directly from the C file through the Dlopen function, the GCC compiler does not know which function the so needs to call, so it does not say that the function is placed in the dynamic segment. Therefore, when you look for a function or variable, there is a case where you cannot find a symbol in the executable program.

Why does it appear that you need to dlopen the dynamic library directly in the C file? This situation generally does not want to restart the implementation, but also need to have functional updates. For example Nginx server, do not restart the Web server, you need to add a filter module, the filter module must be access to nginx internal functions and variables, in this case, the problem is cited.

How do you share variables? What is the mechanism by which Linux is shared? Let's take a look at an example.

HELLO.C used to compile into libhello.so

void Hello () {        share_fun ();}

MAIN.C main function

#include <stdio.h> #include <dlfcn.h>void share_fun () {        printf ("aa\n");} Main () {        void *ptr = NULL;        void (*hello) (void);        ptr = Dlopen ("/home/mywork/libhello.so", rtld_lazy);        if (ptr = = NULL) {                printf ("Error dlopen\n");                return-1;        }        Hello = Dlsym (ptr, "hello");        if (hello = = NULL) {                printf ("Error get fun\n");                return-1;        }        Hello ();        return 0;}

As we can see in the two files, the Share_fun function is accessed in the shared library libhello.so, and this function is defined in the main file.

Let's say hello.c compiled into libhello.so with the following command

gcc-fpic-shared libhello.so hello.c

Generate the main executable file with the following command.

GCC Main.c-o MAIN-LDL

Execution results

./main:symbol Lookup Error:/home/mywork/libhello.so:undefined symbol:share_fun

Generate the main executable file with the following command.

GCC Main.c-o main-ldl-l./-lhello

Execution results

Aa

Why does this happen? First look at how the dynamic libraries in Linux access undefined symbols, the following is the location of Share_fun in the elf file in libhello.so:

Relocation section '. REL.PLT' At offset 0x374 contains 3 entries:
Offset Info Type sym.value Sym. Name
0000200c 00000207 R_386_jump_slot 00000000 Share_fun
00002010 00000307 R_386_jump_slot 00000000 __cxa_finalize
00002014 00000407 R_386_jump_slot 00000000 __gmon_start__

The decoding of unwind sections for machine type Intel 80386 are not currently supported.

Symbol table '. Dynsym' Contains entries:
Num:value Size Type Bind Vis Ndx Name
0:00000000 0 notype LOCAL DEFAULT UND
1:00000000 0 notype WEAK DEFAULT UND _itm_deregistertmclonetab
2:00000000 0 notype GLOBAL DEFAULT UND share_fun
3:00000000 0 FUNC WEAK DEFAULT UND [email protected]_2.1.3 (2)
4:00000000 0 notype WEAK DEFAULT UND __gmon_start__
5:00000000 0 notype WEAK DEFAULT UND _jv_registerclasses

As can be seen from the above share_fun because there is no definition in the dynamic library, so it is placed in the redirect segment, that is, at compile time can not determine the exact address of the function, need to run loading can be determined.

And we can also see that the Share_fun is set as a dynamic symbol.

In the first case, the dynamic symbol in main is not share_fun

[Email protected] mywork]# gcc main.c-o main-ldl
[Email protected] mywork]#./main
./main:symbol Lookup Error:/home/mywork/libhello.so:undefined symbol:share_fun
[Email protected] mywork]# nm-d main
0804867c R _io_stdin_used
W _itm_deregistertmclonetable
W _itm_registertmclonetable
W _jv_registerclasses
W __gmon_start__
U __libc_start_main
U Dlopen
U Dlsym
U puts

In the second case, the dynamic symbol table in main contains Share_fun

[Email protected] mywork]# gcc main.c-o main-ldl-l./-lhello
[Email protected] mywork]#./main
Aa
[Email protected] mywork]# nm-d main
0804873c R _io_stdin_used
W _itm_deregistertmclonetable
W _itm_registertmclonetable
W _jv_registerclasses
0804a024 B __bss_start
W __gmon_start__
U __libc_start_main
0804a024 D _edata
0804a028 B _end
08048724 T _fini
0804847c T _init
U Dlopen
U Dlsym
U puts
08048610 T Share_fun

From the above you can see the function of accessing the main program in the dynamic library, the share of the symbol is realized by the dynamic segment, when there is no dynamic segment, it cannot be shared, and the functions and variables are the same.

In principle, a dynamic library or a function that is not defined in the main program is in the redirect table and needs to be dynamically mapped during the loading phase of the program, so the main program and the dynamic Library sharing and static compilation are conflicting.

Knowing the principle, it is easy to solve the solution, the following compilation options can be exported to dynamic segments, so that the main program and dynamic library symbol access.

-bsymbolic
When creating a GKFX library, bind references to global symbols to the definition within the shared library, if any. Normally, it's possible for a
Program linked against a GKFX library to override the definition within the shared library. This option is a meaningful on ELF platforms which
Support shared libraries.


-bsymbolic-functions
When creating a GKFX library, bind references to global function symbols to the definition within the shared library, if  Any. This option was only
Meaningful on ELF platforms which support shared libraries.


--dynamic-list=dynamic-list-file
Specify the name of a dynamic list file to the linker. This was typically used when creating GKFX libraries to specify a list of global symbols whose
References shouldn ' t being bound to the definition within the shared library, or creating dynamically linked executables to s Pecify a list of symbols which
Should is added to the symbol table in the executable. This option is a meaningful on ELF platforms which support shared libraries.


The format of the dynamic list is the same as the version node without scope and node name. See VERSION for more information.


--dynamic-list-data
Include all global data symbols to the dynamic list.

Variable and function access between Linux master files and dynamic libraries