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
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
