Unresolved Symbols using RTL on pc686
Hickey, Joseph P. (GRC-LSS0)[Vantage Partners, LLC]
joseph.p.hickey at nasa.gov
Mon Sep 24 19:41:06 UTC 2018
Hi All --
I'm currently seeing some unexpected behavior where references to
non-initialized global variables inside a loaded module are not getting
resolved properly after dlopen().I'm using RTEMS 4.11.3 with the pc686 BSP.
This is reproducible using the libtests that are distributed with RTEMS
source, simply by adding a global variable to the module source file.
For instance, in the "dl01" test, in the source file
"/testsuites/libtests/dl01/dl-o1.c", I simply added "my_value" at global
scope and a printf() statement that references its address, like so:
unsigned char my_value;
int rtems_main (int argc, char* argv[])
{
int arg;
printf("Loaded module: argc:%d [%s]\n", argc, __FILE__);
for (arg = 0; arg < argc; ++arg)
printf(" %d: %s\n", arg, argv[arg]);
printf("my_value address=%p\n", &my_value);
return argc;
}
Now when I execute the dl01 test, it does not load correctly:
handle: 0x161f64 has unresolved externals
my_value address=0x0
However, if one simply initializes the global, as in:
unsigned char my_value = 0;
Then the module loads fine, with no unresolved symbols, and the printf()
statement prints a non-null address, as expected.
The only difference here that I've been able to identify thus far is
that uninitialized C variables get placed in the "COMMON" section of the
ELF file, while initialized variables get put in the .bss section.
Are there any known limitations to the RTL linker in this regard?
Thanks in advance for any advice/assistance!
More information about the users
mailing list