Unresolved Symbols using RTL on pc686

[Chris Johns]

On 25/09/2018 05:41, Hickey, Joseph P. (GRC-LSS0)[Vantage Partners, LLC] wrote:
> Hi All --

Hello and welcome.

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

There should not be.

> 
> Thanks in advance for any advice/assistance!
> 

Could you please create a ticket on the 4.11 branch with this information?

The releases table under the Releases heading on https://devel.rtems.org/ has a
link to creating a bug.

Thanks
Chris