From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 84C093858D1E; Mon, 27 Feb 2023 08:48:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 84C093858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677487735; bh=NxKgjXeGoPOhMidCP5spyCTfMzQcxAmLorMsA+jy6iE=; h=From:To:Subject:Date:From; b=S1pVDjH+m3Yd1eDM7BtfccP4LvjZZKGjJWCOIqUwUS+aPvL/Q+nuIqojnEFfqenK0 v9aLtygC4gtZ9o5f6JVsZGnHbh3xNgJIHydQq3kxmau9FN81eHOsevhQxJvgnC+7KL S4IcyoyTwEVykzu+PCzb3Ch39YinkEQTpaoq+xGo= From: "rob.meades@u-blox.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108940] New: Offset of pointer to global variable not set correctly for position independent executable Date: Mon, 27 Feb 2023 08:48:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rob.meades@u-blox.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108940 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/gn= u/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 glob= al 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 =3D 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 disassem= bly of the above, as compiled with the flags indicated above: 00000188 : 188: b580 push {r7, lr} 18a: af00 add r7, sp, #0 18c: 4b1a ldr r3, [pc, #104] ; (1f8 ) 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 ) 198: f859 3003 ldr.w r3, [r9, r3] 19c: 4619 mov r1, r3 19e: 4b18 ldr r3, [pc, #96] ; (200 ) 1a0: f859 3003 ldr.w r3, [r9, r3] 1a4: 4618 mov r0, r3 1a6: f000 f8bb bl 320 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 : 100001d0: 1000025c ...while 1000025c in the disassembled output turns out to be: Disassembly of section .bss: ... 1000025c : ... So pBuffer is initialised to the un-offsetted address of buffer and nothing corrects that to the real address.=