[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #8 from wangwen at microsoft dot com --- I posted it in the wrong place, please just delete it. thank you.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #7 from Xi Ruoyao --- (In reply to wangwen from comment #6) > would anyone guide me any place to ask such question? You are building the .o files with -fpie, but have you linked the executable with -pie? Note that -fpie and -pie are two different options, -fpie is for the compiler but -pie is for the linker. W/o -pie the linker will just produce a non-position-independent executable which can be only loaded at a fixed address, even if you've built all .o files with -fpie. With -pie the linker will emit some relative relocation entries in a section of the outputted PIE. And when you load the executable, either the loader or the executable itself must "resolve" the relocation, i. e. read each relocation entry and use the info recorded in the entry to fix up the addresses of global objects. Andrew has already explained this. If you still don't understand, it indicates you lack the knowledge about how PIE works in general. Then Google will find some nice articles explaining PIE in detail. Any project-specific support channel won't be proper for asking such a question about a general concept.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #6 from wangwen at microsoft dot com --- would anyone guide me any place to ask such question?
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Xi Ruoyao --- Anyway Bugzilla is not a place for asking questions.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #4 from Andrew Pinski --- (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.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #3 from wangwen at microsoft dot com --- 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
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #2 from Andrew Pinski --- as far as I understand, there will be a relocation section which is there for runtime relocations and they basically "instructions" on how the relocation should happen including the location of where the relocation will happen.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #1 from Andrew Pinski --- I don't understand your question since if we look at the output of GCC we get: .LC0: .ascii "const char *text\000" .section.data.rel.local,"aw" .align 2 .type user_test, %object .size user_test, 112 user_test: .ascii "struct member testChArray\000" .space 74 .word 10 .word .LC0 .word 27 Only text will have a relocation associated with it since that is the only one that needs it. Everything else has no need for a relocation since it is just data.