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