public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/108940] New: Offset of pointer to global variable not set correctly for position independent executable
@ 2023-02-27 8:48 rob.meades@u-blox.com
2023-02-27 13:10 ` [Bug target/108940] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: rob.meades@u-blox.com @ 2023-02-27 8:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-02-27 16:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-27 8:48 [Bug c/108940] New: Offset of pointer to global variable not set correctly for position independent executable rob.meades@u-blox.com
2023-02-27 13:10 ` [Bug target/108940] " pinskia at gcc dot gnu.org
2023-02-27 13:15 ` rob.meades@u-blox.com
2023-02-27 16:22 ` pinskia at gcc dot gnu.org
2023-02-27 16:26 ` pinskia at gcc dot gnu.org
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).