From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web10.11201.1655921914402143961 for ; Wed, 22 Jun 2022 11:18:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=bETjo5P5; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 25MIINHh015876; Wed, 22 Jun 2022 11:18:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=9f7zwcMpil/sjAvegD/veoMQxgtEkBz/I5TljD8bzgA=; b=bETjo5P5xQFZ8r6gzQQvE0dL9F22vPqfP0KfGObVByZpQAb4G8eiF4+5ihiuGyj4lo/I knjNgYnMsb9/mEXN9eTuDNa4DURt14vJ5TROQaU9IzsWWRrZfgORUJVqTrSH+hVx+kWY f151L3m9USOt1orNl11JmcAyUyOpc1niJuFbkofniRT/iMf2orkO/PerNGfHHAKrwLFR GV7vwg6AyJWHHQ84F612IdexQa8qZtYXH9en/L6Mb7sv0xDIOu7WNwkuuegArxzs41p9 HpzsDYORVmny8s36f0wewAykv8Z3hsb63USSYtzM+py3olXdBjoZ4tj8Zx/bzWRfxAsO cg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 3gsbctu4n4-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Jun 2022 11:18:25 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RDW00NSG5IOMC80@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 22 Jun 2022 11:18:24 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RDW0070050M4A00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 22 Jun 2022 11:18:24 -0700 (PDT) X-Va-A: X-Va-T-CD: cb83049425a79c8a5fb9f1dafa0fda92 X-Va-E-CD: 34d828171d62a66504fe446d19c636f0 X-Va-R-CD: a2e620c742550a3a5a5b3202624e2dc2 X-Va-CD: 0 X-Va-ID: 6db94751-2aad-463c-bed5-dc2d6032bf23 X-V-A: X-V-T-CD: cb83049425a79c8a5fb9f1dafa0fda92 X-V-E-CD: 34d828171d62a66504fe446d19c636f0 X-V-R-CD: a2e620c742550a3a5a5b3202624e2dc2 X-V-CD: 0 X-V-ID: a95eee03-aab8-4bad-9169-9e9955c346c1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-22_05:2022-06-22,2022-06-22 signatures=0 Received: from smtpclient.apple (unknown [17.235.53.23]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RDW00AFA5IN3H00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 22 Jun 2022 11:18:24 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Suppress read only relocs errors on XCODE5 X64 toolchain From: "Andrew Fish" In-reply-to: Date: Wed, 22 Jun 2022 11:18:22 -0700 Cc: edk2-devel-groups-io , =?utf-8?Q?Th=C3=A9o_Jehl?= , Bob Feng , Liming Gao , Yuwei Chen , Vitaly Cheptsov , Rebecca Cran , Pedro Falcato , Isaac W Oram Message-id: <34AF20A4-8FF4-4971-9754-EEE36091EA9D@apple.com> References: <5C4BDE52-3FA5-4683-ABF2-FEEB447A6DCE@apple.com> To: =?utf-8?Q?Marvin_H=C3=A4user?= X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-22_05:2022-06-22,2022-06-22 signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 22, 2022, at 10:43 AM, Marvin H=C3=A4user wro= te: >=20 > Hey Andrew, >=20 > thanks for verifying! If my last mail was not clear, this is already done= for IA32 builds, by the way. I suspect more trouble appeared there due to = the lack of IP-relative addressing. >=20 I though the issue was on x86_64 since by default that does not support rel= ocations in .text sections. The maintainer mentioned this should work for x= 86_64 but is not really tested. If it works in our case we should be good t= o go. The compiler always generates RIP relative addressing in the text sec= tion. It is humans that generate absolution addressing by trying to access = labels directly.=20 I tested the change the flags on some some existing code bases and booted o= n real hardware and in a VM. I did not force a relocation into a text secti= on, I just tested existing platforms as is. Historically what would happen is any assembler that generated a relocation= in the .text section would fail to link with Xcode and we would have to co= nvert it to RIP relative addressing after the fact.=20 Thanks, Andrew Fish > Theo wanted to prepare a V2 with an enhanced commit message and a 2nd pat= ch to remove the related hacks, I believe. >=20 > Best regards, > Marvin >=20 >> On 22. Jun 2022, at 19:22, Andrew Fish wrote: >>=20 >> =EF=BB=BFI reached out to the Xcode ld64 maintainer to make sure it is s= afe to use -read_only_relocs suppress this way.=20 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> On Jun 18, 2022, at 8:19 PM, Andrew Fish via groups.io wrote: >>>=20 >>> Marvin, >>>=20 >>> I=E2=80=99ll look into this. >>>=20 >>> The history here is the original ld64 flags are what was required for p= roper function. I got them >>> directly from the main ld64 maintainer.=20 >>>=20 >>> Big picture ld64 is the macOS and iOS linker, and it does not have offi= cial support for other targets, especially embedded. So the combination of = flags are what was required for correctness as not all combination of possi= ble ld64 flags are actually supported. >>>=20 >>> Back in the day we made clang open source contributions to get EFIABI s= upported in clang, but we have always used the stock ld64, with help from t= he author. >>>>> On Jun 18, 2022, at 8:03 PM, Marvin H=C3=A4user = wrote: >>>>=20 >>>> =EF=BB=BFCC Andrew, Rebecca, mentors >>>>=20 >>>> Hey all, >>>>=20 >>>> The patch itself looks good to me. The description doesn't really capt= ure the issue, nor why this is an adequate solution. This should also remov= e the mentioned XCODE5-specific code as part of a single series [1] to conf= irm the issue has been resolved without regressions. >>>>=20 >>>> TL;dr for the rest: Apple ld64 complains because there are relocations= to read-only segments in a PIE executable. As Mach-O allows mapping read-o= nly segments of PIEs to multiple virtual addresses (in different processes)= , this is prohibited right at link-time for obvious reasons. PE/COFF doesn'= t really have such a feature (I think Windows used to use static addresses = and now uses CoW with traditional relocs?) and UEFI has no concept of page = sharing anyway. Hence, it is safe to allow such relocs and silence the warn= ing. All other toolchains should already work this way. >>>>=20 >>>> Andrew, Rebecca, if I remember correctly, you pretty much maintain XCO= DE5. I had a conversation with Andrew about related topics before, too. Are= you fine with this approach? It seems like it has previously been applied = to IA32 builds already anyway (right from import). >>>>=20 >>>> Maybe PIE could be dropped as a whole somehow in the future? For UEFI,= it basically only adds overhead (or are there blockers to this?). >>>>=20 >>>> Best regards, >>>> Marvin >>>>=20 >>>> [1] https://github.com/tianocore/edk2/tree/cc2db6ebfb6d9d85ba4c7b35fba= 1fa37fffc0bc2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5Exception= HandlerAsm.nasm >>>>=20 >>>>> On 18. Jun 2022, at 15:21, Th=C3=A9o Jehl wrot= e: >>>>>=20 >>>>> From: Theo Jehl >>>>>=20 >>>>> Added -read_only_relocs suppress for XCODE5 X64 toolchain >>>>> This remove the needs for XCODE5 specific source with relocation fixe= s >>>>>=20 >>>>> Cc: Bob Feng >>>>> Cc: Liming Gao >>>>> Cc: Yuwei Chen >>>>> Cc: Marvin H=C3=A4user >>>>> Cc: Vitaly Cheptsov >>>>>=20 >>>>> Signed-off-by: Theo Jehl >>>>> --- >>>>> BaseTools/Conf/tools_def.template | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>=20 >>>>> diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools= _def.template >>>>> index 5ed19810b727..be35094cecc3 100755 >>>>> --- a/BaseTools/Conf/tools_def.template >>>>> +++ b/BaseTools/Conf/tools_def.template >>>>> @@ -2977,9 +2977,9 @@ RELEASE_XCODE5_IA32_CC_FLAGS =3D -arch i386 -= c -Os -Wall -Werror -inclu >>>>> ################## >>>>> # X64 definitions >>>>> ################## >>>>> - DEBUG_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map >>>>> - NOOPT_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map >>>>> -RELEASE_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map >>>>> + DEBUG_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map $(DEST_DIR_DEBU= G)/$(BASE_NAME).map >>>>> + NOOPT_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map $(DEST_DIR_DEBU= G)/$(BASE_NAME).map >>>>> +RELEASE_XCODE5_X64_DLINK_FLAGS =3D -arch x86_64 -u _$(IMAGE_ENT= RY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20 -pie -all_load = -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map $(DEST_DIR_DEBU= G)/$(BASE_NAME).map >>>>>=20 >>>>> *_XCODE5_X64_SLINK_FLAGS =3D -static -o >>>>> DEBUG_XCODE5_X64_ASM_FLAGS =3D -arch x86_64 -g >>>>> --=20 >>>>> 2.32.1 (Apple Git-133) >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20