[Bug c/108940] New: Offset of pointer to global variable not set correctly for position independent executable

["rob.meades@u-blox.com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 108940
           Summary: Offset of pointer to global variable not set correctly
                    for position independent executable
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rob.meades@u-blox.com
  Target Milestone: ---

We are compiling C as position independent code on a Cortex-M7 under GCC 12.2
release 1, using the default r9 as the offset register for the Global Offset
Table with:

-fpie -fno-plt -mno-pic-data-is-text-relative -msingle-pic-base

...and no particular linker options (as recommended by ThreadX Modules (see
https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/build_threadx_module_sample.bat),
which manages r9 during loading).

The problem we are having is that any attempt to take the address of a global
variable ends up with the wrong address (the un-offsetted address) and this
appears to be how the assembly code is being written by GCC, there appears
nothing we can do in terms of r9 etc. to fix it: is there a compiler flag we
have failed to add/[remove] that would fix this, or is such an operation
impossible when the offset-register mechanism is employed, or could this be a
bug?  Obviously we have tried many permutations of the "pic"-related flags but
have not found a combination which gives us the correct pointer address.

Our sample code:

char buffer[100];
char* pBuffer = buffer;

int appModMain()
{
    printf("buffer address: %p, buffer address via pBuffer: %p \n", buffer,
pBuffer);
}

...results in printed output of the form:

buffer address:  60C8C25C, buffer address via pBuffer: 1000025C

In other words pBuffer is not being offset correctly.  Here is the disassembly
of the above, as compiled with the flags indicated above:

00000188 <appModMain>:
     188:   b580        push    {r7, lr}
     18a:   af00        add r7, sp, #0
     18c:   4b1a        ldr r3, [pc, #104]  ; (1f8 <appModMain+0x70>)
     18e:   f859 3003   ldr.w   r3, [r9, r3]
     192:   681b        ldr r3, [r3, #0]
     194:   461a        mov r2, r3
     196:   4b19        ldr r3, [pc, #100]  ; (1fc <appModMain+0x74>)
     198:   f859 3003   ldr.w   r3, [r9, r3]
     19c:   4619        mov r1, r3
     19e:   4b18        ldr r3, [pc, #96]   ; (200 <appModMain+0x78>)
     1a0:   f859 3003   ldr.w   r3, [r9, r3]
     1a4:   4618        mov r0, r3
     1a6:   f000 f8bb   bl  320 <printf>
     1aa:   f640 30b8   movw    r0, #3000   ; 0xbb8

The contents of 1f8 and 1fc for the above are:

     1f8:       000001bc
     1fc:       000001b0

...in the .got section of the disassembled output, these offset are towards the
end, here:


Disassembly of section .got:
00006b88 <__ctors_end__>:
...
    6d34:       1002c5a8
    6d38:       1000025c    ; 6b88 + 1b0
    6d3c:       00001e15
    6d40:       1002c5ac
    6d44:       100001d0        ; 6b88 + 1bc

...and 100001d0 in the disassembled output turns out to be:

Disassembly of section .data:
...

100001d0 <pBuffer>:
100001d0:       1000025c

...while 1000025c in the disassembled output turns out to be:


Disassembly of section .bss:
...

1000025c <buffer>:
        ...

So pBuffer is initialised to the un-offsetted address of buffer and nothing
corrects that to the real address.