From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.56843.1680273789653100230 for ; Fri, 31 Mar 2023 07:43:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=TqdaCfAr; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CB7DE2402DC for ; Fri, 31 Mar 2023 16:43:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1680273787; bh=MIGpiZUIUB+M3Xt3kXhRo2Tb7xFCRArcia8rOnNceXY=; h=From:Subject:Date:Cc:To:From; b=TqdaCfArWAp2tMQAYzvCcBJdm3w5S4WNlcEcZE0AUkZc9M59LvBZ4B29fZMRPxOZt GLrPTpNY8CWQrI6FUrTUMSi9c5g5xyxQIyKd3i8tNDjwMqH9/Gns372FRS204Luhcu eFL8vx+XSHk/FbEAdnbofTkjr/xO2u0j6XPOy4xX18N9++RcbqXJE/giSnRL4ZusIo hK2LCGunNr7J+oKYa3sbVTORJoBnLhSwnRiAPTENQ9zfBKd0Ki0Adk2Sg+g1JDiKCW b5D4CK8krETx93o1a7/CuP6chpTz6xeo3oUJynwiYriVK71A+ogunHlSbxQ+KwLIR8 8HTDtjzEm83lw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pp31Q2rtZz9rxD; Fri, 31 Mar 2023 16:43:06 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-Id: <0DD346A3-80BD-4489-B5BA-102B3E55179F@posteo.de> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib Date: Fri, 31 Mar 2023 14:42:55 +0000 In-Reply-To: Cc: "devel@edk2.groups.io" , Ard Biesheuvel , Andrew Fish , "Kinney, Michael D" , "Liu, Zhiguang" , Rebecca Cran , Tom Lendacky To: "Ni, Ray" References: Content-Type: multipart/alternative; boundary="Apple-Mail=_79368444-05BB-4A22-8C47-F6BBF68D5B3B" --Apple-Mail=_79368444-05BB-4A22-8C47-F6BBF68D5B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31. Mar 2023, at 16:39, Ni, Ray wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Marvin >> H=C3=A4user >> Sent: Friday, March 31, 2023 7:10 PM >> To: Ard Biesheuvel >> Cc: Ni, Ray ; devel@edk2.groups.io; Andrew Fish >> ; Kinney, Michael D ; Liu, >> Zhiguang ; Rebecca Cran ; >> Tom Lendacky >> Subject: Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simpli= fy >> CpuExceptionHandlerLib >>=20 >>=20 >>> On 31. Mar 2023, at 13:03, Ard Biesheuvel wrote: >>>=20 >>> =EF=BB=BFOn Fri, 31 Mar 2023 at 12:41, Marvin H=C3=A4user wrote: >>>>=20 >>>> Hi Ray, >>>>=20 >>>>>> On 31. Mar 2023, at 12:09, Ni, Ray wrote: >>>>>=20 >>>>> =EF=BB=BFArd, >>>>> What does "-read_only_relocs suppress" control? >>>>=20 >>>> It controls whether relocs that target read-only segments yield a buil= d >> error or not. I think lld uses =E2=80=9C-z notext=E2=80=9D. >>>>=20 >>>>> Linker doesn't produce relocation entries that modifies .text section >> silently >>>>> so the final .text just cannot run at all? >>>>=20 >>>> Could you please rephrase? I=E2=80=99m not sure I understand, but I th= ink it=E2=80=99s >> important everyone understands the issues at play to make a good judgmen= t >> call. >>>>=20 >>>=20 >>> As *I* understood it, it means suppress the *warning* not suppress the >>> *relocation* >=20 > What the meaning of "suppress relocation"? The option naming is just a bit odd, it suppresses the warning about reloca= tions to read-only segments, not the relocations themselves. > Why the final binaries are not executable? I explained that here: https://edk2.groups.io/g/devel/message/102219 TL;dr: Relocations are relative to the first writable segment (thus usually= __DATA), so relocations to preceding segments (usually __TEXT) will underf= low and thus get corrupted offsets. Best regards, Marvin >=20 >>=20 >> Correct. >>=20 >>>=20 >>> But the resulting binaries are broken, so it doesn't really matter. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 --Apple-Mail=_79368444-05BB-4A22-8C47-F6BBF68D5B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 31. Mar 2023, at 16:39, Ni, Ray <ray.ni@intel.com> wrote:


-----Original Message-----
From: devel@edk2.groups.io <d= evel@edk2.groups.io> On Behalf Of Marvin
H=C3=A4user
Sent: Friday,= March 31, 2023 7:10 PM
To: Ard Biesheuvel <ardb@kernel.org>
Cc= : Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Andrew Fish
&l= t;afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>= ; Liu,
Zhiguang <zhiguang.liu@intel.com>; Rebecca Cran <rebecca= @bsdio.com>;
Tom Lendacky <thomas.lendacky@amd.com>
Subject:= Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify
CpuEx= ceptionHandlerLib


On 31. Mar 2023, at = 13:03, Ard Biesheuvel <ardb@kernel.org> wrote:

=EF=BB=BFOn Fri= , 31 Mar 2023 at 12:41, Marvin H=C3=A4user <mhaeuser@posteo.de> wrote= :

Hi Ray,

On 31. Mar 2023, at 12:09, Ni, Ray <ray.ni@in= tel.com> wrote:

=EF=BB=BFArd,
What does "-read_on= ly_relocs suppress" control?

It controls whether relocs= that target read-only segments yield a build
= error or not. I think lld uses =E2=80=9C-z notext=E2=80=9D.

Linke= r doesn't produce relocation entries that modifies .text section
silently
so the final .text just cann= ot run at all?

Could you please rephrase? I=E2=80=99m n= ot sure I understand, but I think it=E2=80=99s
important everyone understands the issues at play to make a good judgment<= br>call.


As *I* understood it, it means suppress the *warning* not suppres= s the
*relocation*

What the meaning of = "suppress relocation"?

The = option naming is just a bit odd, it suppresses the warning about relocation= s to read-only segments, not the relocations themselves.

Why the final binaries are not executable?


TL;dr: Relocations ar= e relative to the first writable segment (thus usually __DATA), so relocati= ons to preceding segments (usually __TEXT) will underflow and thus get corr= upted offsets.

Best regards,
Marvin


= Correct.


But the resulting binaries ar= e broken, so it doesn't really matter.





=


--Apple-Mail=_79368444-05BB-4A22-8C47-F6BBF68D5B3B--