public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application.
@ 2023-07-18  4:09 wangwen at microsoft dot com
  2023-07-18  4:19 ` [Bug target/110709] " pinskia at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: wangwen at microsoft dot com @ 2023-07-18  4:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709

            Bug ID: 110709
           Summary: how to handle the initialization of global struct data
                    for position independent executable application.
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wangwen at microsoft dot com
  Target Milestone: ---

our project is to dynamically load applications in azure-rtos. the application
is compiled with "-O0 -ffunction-sections -Wall -fno-plt -fpie
-msingle-pic-base -mno-pic-data-is-text-relative -fPIC"

when there are global variables defined in below ways, the initialized value of
struct members can't be loaded correctly.
"
typedef struct
{
char testChArray[100];
int test_A;
const char *text;
int test_B;

}GCC_TEST_t;

GCC_TEST_t user_test = {"struct member testChArray",10,"const char *text",27};

"

if the pointer member "text" is initialized when "user_test" is declared. the
"user_test" will be placed at section ".data.rel.local"; but other members like
"testChArray" would be initialized with relocated value which would be wrong, 

So we wonder if PIC supports such struct data initialization that struct data
is composed with array and pointer and initialized when declared.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
@ 2023-07-18  4:19 ` pinskia at gcc dot gnu.org
  2023-07-18  4:22 ` pinskia at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18  4:19 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
  2023-07-18  4:19 ` [Bug target/110709] " pinskia at gcc dot gnu.org
@ 2023-07-18  4:22 ` pinskia at gcc dot gnu.org
  2023-07-18  4:39 ` wangwen at microsoft dot com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18  4:22 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
  2023-07-18  4:19 ` [Bug target/110709] " pinskia at gcc dot gnu.org
  2023-07-18  4:22 ` pinskia at gcc dot gnu.org
@ 2023-07-18  4:39 ` wangwen at microsoft dot com
  2023-07-18  5:00 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: wangwen at microsoft dot com @ 2023-07-18  4:39 UTC (permalink / raw)
  To: gcc-bugs

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
                   ` (2 preceding siblings ...)
  2023-07-18  4:39 ` wangwen at microsoft dot com
@ 2023-07-18  5:00 ` pinskia at gcc dot gnu.org
  2023-07-18  7:01 ` xry111 at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18  5:00 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
                   ` (3 preceding siblings ...)
  2023-07-18  5:00 ` pinskia at gcc dot gnu.org
@ 2023-07-18  7:01 ` xry111 at gcc dot gnu.org
  2023-07-18 13:30 ` wangwen at microsoft dot com
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-07-18  7:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Anyway Bugzilla is not a place for asking questions.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
                   ` (4 preceding siblings ...)
  2023-07-18  7:01 ` xry111 at gcc dot gnu.org
@ 2023-07-18 13:30 ` wangwen at microsoft dot com
  2023-07-18 14:05 ` xry111 at gcc dot gnu.org
  2023-07-18 14:41 ` wangwen at microsoft dot com
  7 siblings, 0 replies; 9+ messages in thread
From: wangwen at microsoft dot com @ 2023-07-18 13:30 UTC (permalink / raw)
  To: gcc-bugs

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
                   ` (5 preceding siblings ...)
  2023-07-18 13:30 ` wangwen at microsoft dot com
@ 2023-07-18 14:05 ` xry111 at gcc dot gnu.org
  2023-07-18 14:41 ` wangwen at microsoft dot com
  7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-07-18 14:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709

--- Comment #7 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
  2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
                   ` (6 preceding siblings ...)
  2023-07-18 14:05 ` xry111 at gcc dot gnu.org
@ 2023-07-18 14:41 ` wangwen at microsoft dot com
  7 siblings, 0 replies; 9+ messages in thread
From: wangwen at microsoft dot com @ 2023-07-18 14:41 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-07-18 14:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-18  4:09 [Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application wangwen at microsoft dot com
2023-07-18  4:19 ` [Bug target/110709] " pinskia at gcc dot gnu.org
2023-07-18  4:22 ` pinskia at gcc dot gnu.org
2023-07-18  4:39 ` wangwen at microsoft dot com
2023-07-18  5:00 ` pinskia at gcc dot gnu.org
2023-07-18  7:01 ` xry111 at gcc dot gnu.org
2023-07-18 13:30 ` wangwen at microsoft dot com
2023-07-18 14:05 ` xry111 at gcc dot gnu.org
2023-07-18 14:41 ` wangwen at microsoft dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).