Neither R_X86_64_JUMP_SLOT nor R_X86_64_GLOB_DAT are emitted by GCC so the question is off-topic. I'll explain them briefly though. On Tue, 2023-03-07 at 12:13 +0000, Frederick Virchanza Gotham via Gcc- help wrote: > (1) Is the R_X86_64_JUMP_SLO category just for functions, or can we > put global variables in there too? Is it possible to get 'dlopen' to > resolve global variables? No. > (2) Is there any way to stop the GNU linker from putting an undefined > function in R_X86_64_GLOB_DAT? No, unless you avoid extracting its address. You need to understand how R_X86_64_JUMP_SLOT works. When a program or library is loaded, the dynamic linker do nothing for it. When you call a function foo in a shared library, it's implemented by calling a function called foo@plt first. foo@plt is in the main executable. It attempts to load the address of foo from the GOT and jump to the address. As R_X86_64_JUMP_SLOT is not handled by the dynamic linker, on the first call the GOT does not contains the address of foo. Instead it contains the address of a "resolver function". The resolver calculates the real address of foo, fills it into the GOT, then jumps to the address. In the subsequent calls foo@plt will directly jump to foo as the GOT already contains the address of foo. This obviously won't work for a global variable because you can't call it. This won't work for a function pointer either: the value of the function pointer must be the address of foo itself, not foo@plt. Or the result of &foo in the shared library and the main executable will be different, violating the C or C++ standard. Then we must use R_X86_64_JUMP_SLOT which is handled by the dynamic linker. -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
