https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to wangwen from comment #3) > when the global pointer variety has an initialized value which is not NULL, > then the value should be an address, so the initialized value should be > recalculated when dynamically loaded. > > Now the problem is the array member and pointer member of struct data will > be place at same section, then the loader would not know how to calculate > the initialized value, because it has no idea the value is an address or is > normal data. > > it is a long story if you are interested in how the problem is brought up. > I pasted the link where we are trying to solve it. > https://github.com/azure-rtos/threadx/issues/230 Right, that means you are not processing the runtime relocations here correctly when doing a load of the module. The section .data.rel* just means it will have a runtime relocation which is in its own section. The runtime relocation section is created by the linker. Now if you are not doing a full link, in the object file there are still static relocations. (you can also get keep around relocations by the linker too via the -q/--emit-relocs option too). See https://sourceware.org/binutils/docs-2.40/ld.html there. But this is now outside of a GCC bug/question and really overlaps with the loader of threadx/azure-rtos and the linker.