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.mea...@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: 125C
In other words pBuffer is not being offset correctly. Here is the disassembly
of the above, as compiled with the flags indicated above:
0188 :
188: b580push{r7, lr}
18a: af00add r7, sp, #0
18c: 4b1aldr r3, [pc, #104] ; (1f8 )
18e: f859 3003 ldr.w r3, [r9, r3]
192: 681bldr r3, [r3, #0]
194: 461amov r2, r3
196: 4b19ldr r3, [pc, #100] ; (1fc )
198: f859 3003 ldr.w r3, [r9, r3]
19c: 4619mov r1, r3
19e: 4b18ldr r3, [pc, #96] ; (200 )
1a0: f859 3003 ldr.w r3, [r9, r3]
1a4: 4618mov r0, r3
1a6: f000 f8bb bl 320
1aa: f640 30b8 movwr0, #3000 ; 0xbb8
The contents of 1f8 and 1fc for the above are:
1f8: 01bc
1fc: 01b0
...in the .got section of the disassembled output, these offset are towards the
end, here:
Disassembly of section .got:
6b88 <__ctors_end__>:
...
6d34: 1002c5a8
6d38: 125c; 6b88 + 1b0
6d3c: 1e15
6d40: 1002c5ac
6d44: 11d0; 6b88 + 1bc
...and 11d0 in the disassembled output turns out to be:
Disassembly of section .data:
...
11d0 :
11d0: 125c
...while 125c in the disassembled output turns out to be:
Disassembly of section .bss:
...
125c :
...
So pBuffer is initialised to the un-offsetted address of buffer and nothing
corrects that to the real address.
