Functions and Global Variables defined in Libraries

* Functions and Global Variables defined in Libraries
@ 2023-03-07 12:13 Frederick Virchanza Gotham
  2023-03-07 13:05 ` Xi Ruoyao
  0 siblings, 1 reply; 9+ messages in thread
From: Frederick Virchanza Gotham @ 2023-03-07 12:13 UTC (permalink / raw)
  To: gcc-help

Let's say we have a program that links with a library that exports a
global variable and a function. So the library looks like this:

int lib_global_variable = 0;

void Func(void) { }

The main program has the following declarations:

extern int lib_global_variable;

extern void Func(void);

The program links fine and runs fine if we give the linker "-L.
-lname_of_library".

If we use the program "nm" on the main executable and grep for
"lib_global_variable" and "Func", we see that both are listed as
undefined symbols:

U lib_global_variable
U _Z7LibFuncv

If we use 'readelf' on the main executable and grep for the same two
symbols, we see:

000000003fc8 000700000006 R_X86_64_GLOB_DAT 0000000000000000
lib_global_variable + 0
000000004038 000900000007 R_X86_64_JUMP_SLO 0000000000000000 _Z7LibFuncv + 0
7: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND lib_global_variable
9: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _Z7LibFuncv
39: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND lib_global_variable
41: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _Z7LibFuncv

I've been doing some testing and tinkering, and I've found that the
strategy of using 'dlopen' at runtime to load a library works fine so
long as the undefined symbol is listed under R_X86_64_JUMP_SLO. It
doesn't work if the symbol is listed under R_X86_64_GLOB_DAT.

Typically all undefined functions get listed under R_X86_64_JUMP_SLO,
and all global variables get listed under R_X86_64_GLOB_DAT, however
it is possible to get functions listed under R_X86_64_GLOB_DAT, and my
strategy of using 'dlopen' doesn't work if the function is under
R_X86_64_GLOB_DAT.

It seems that GNU g++ by default puts the undefined function under
R_X86_64_JUMP_SLO, however if you try to use the address of the
function at all, for example:

cout << (std::uintptr_t)(void*)LibFunc << endl;

then the function gets moved to R_X86_64_GLOB_DAT, and then my
strategy no longer works as 'dlopen' doesn't resolve the unresolved
symbol.

So I'd like to ask two questions:

(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?

(2) Is there any way to stop the GNU linker from putting an undefined
function in R_X86_64_GLOB_DAT?

^ permalink raw reply	[flat|nested] 9+ messages in thread