From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from loongson.cn (loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web10.91729.1680575069522133083 for ; Mon, 03 Apr 2023 19:24:30 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: loongson.cn, ip: 114.242.206.163, mailfrom: lichao@loongson.cn) Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8Axz_9Ziitkl0sWAA--.34417S3; Tue, 04 Apr 2023 10:24:26 +0800 (CST) Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Cxur1WiitkSOIUAA--.18919S3; Tue, 04 Apr 2023 10:24:22 +0800 (CST) Message-ID: <84a503cd-82a4-5509-9629-da93c9e3ba64@loongson.cn> Date: Tue, 4 Apr 2023 10:24:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process To: devel@edk2.groups.io, kraxel@redhat.com, mcb30@ipxe.org Cc: maobibo@loongson.cn, WANG Xuerui , qemu-devel , Song Gao , =?UTF-8?B?5p2o5bCP5aif?= References: <1f1d3d9f-c3df-4f29-df66-886410994cc3@xen0n.name> <67517424-0f32-09f8-6446-53f71ebd59b5@loongson.cn> <317e3008-e2bd-8af6-2cf5-dad49d98cb8d@loongson.cn> <0102018746aa8382-eabf5475-59a6-4741-a8b1-ca3d5b49da92-000000@eu-west-1.amazonses.com> From: "Chao Li" In-Reply-To: X-CM-TRANSID: AQAAf8Cxur1WiitkSOIUAA--.18919S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQALCGQqwfgLFQABsq X-Coremail-Antispam: 1Uk129KBjvJXoWxAF17try5ur43KryrCFWDtwb_yoW5WFWUpF 47u39Iyr1qy3WIvrW0gw1Ig3WF9a109F15Jas0v3y0yF4fuFs5tw17Kr4qya4fZwnYva12 vFyYq345JF4DC37anT9S1TB71UUUUjUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj DUYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUUbf8YFVCjjxCrM7AC8VAFwI0_Jr0_ Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFV AK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2 z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr 1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1ln4kS14v26r1Y6r17M2AIxVAIcxkE cVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1lYx0E2Ix0cI8IcVAFwI0_JF 0_Jw1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxG rwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwI xGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AKxVWUXVWUAwC20s026c02F40E 14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r 4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1hZ2DUU UUU== Content-Type: multipart/alternative; boundary="------------u3DaISOVAHtz3Qrrm9alBZjE" --------------u3DaISOVAHtz3Qrrm9alBZjE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2023/4/3 19:04, Gerd Hoffmann 写道: > On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote: >> On 03/04/2023 11:13, Chao Li wrote: >>> This problem is because the gcc-12 does not yet to support the option >>> 'mno-explicit-reloc', this option is used to open the new reloaction >>> type for LoongArch, this new feature is very important for LoongArch, >>> because it can reduce the binary size and improve code execution >>> efficiency, so we turn it on when submitting the code to the EDK2 repo. >> Is it possible to produce a _functional_ LoongArch64 EDK2 binary without >> this option, even if the resulting binary is less efficient? > MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch > relocation type only, which I expect being the new type. So I suspect > the answer is "no" because the edk2 pe loader isn't able to handle the > old relocation type(s). Yes, the answer is "no", but the opposite is ture, the MdePkg/Include/IndustryStandard/PeImage.h LoongArch relocation type is older, this type appears in this list for compatiblility with binaries using the old reloaction type. If you use this type, you have to turn on the option '-mla-global-with-abs' in gcc,all global symbols will be created as "mark la" type, PE loader will use this rule to handle them. This option is mutually exclusive with 'mno-explicit-reloc',  new reloaction type(s) doesn't require special type(s) to be expressed in PeImage.h, PE loader doesn't need to do anything about relocation, all of reloaction process is done in BaseTools/Source/C/GenFw/Elf64Convert.c. Thanks, Chao 在 2023/4/3 19:04, Gerd Hoffmann 写道: > On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote: >> On 03/04/2023 11:13, Chao Li wrote: >>> This problem is because the gcc-12 does not yet to support the option >>> 'mno-explicit-reloc', this option is used to open the new reloaction >>> type for LoongArch, this new feature is very important for LoongArch, >>> because it can reduce the binary size and improve code execution >>> efficiency, so we turn it on when submitting the code to the EDK2 repo. >> Is it possible to produce a _functional_ LoongArch64 EDK2 binary without >> this option, even if the resulting binary is less efficient? > MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch > relocation type only, which I expect being the new type. So I suspect > the answer is "no" because the edk2 pe loader isn't able to handle the > old relocation type(s). > > take care, > Gerd > > > > > --------------u3DaISOVAHtz3Qrrm9alBZjE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

在 2023/4/3 19:04, Gerd Hoffmann 写道:

On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote:

On 03/04/2023 11:13, Chao Li wrote:

This problem is because the gcc-12 does not yet to support the option
'mno-explicit-reloc', this option is used to open the new reloaction
type for LoongArch, this new feature is very important for LoongArch,
because it can reduce the binary size and improve code execution
efficiency, so we turn it on when submitting the code to the EDK2 repo.

Is it possible to produce a _functional_ LoongArch64 EDK2 binary without
this option, even if the resulting binary is less efficient?

MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch
relocation type only, which I expect being the new type.  So I suspect
the answer is "no" because the edk2 pe loader isn't able to handle the
old relocation type(s).

Yes, the answer is "no", but the opposite is ture, the MdePkg/Include/IndustryStandard/PeImage.h LoongArch relocation type is older, this type appears in this list for compatiblility with binaries using the old reloaction type. If you use this type, you have to turn on the option '-mla-global-with-abs' in gcc, all global symbols will be created as "mark la" type, PE loader will use this rule to handle them. This option is mutually exclusive with 'mno-explicit-reloc',  new reloaction type(s) doesn't require special type(s) to be expressed in PeImage.h, PE loader doesn't need to do anything about relocation, all of reloaction process is done in BaseTools/Source/C/GenFw/Elf64Convert.c.


Thanks,
Chao
在 2023/4/3 19:04, Gerd Hoffmann 写道:
On Mon, Apr 03, 2023 at 10:29:52AM +0000, Michael Brown wrote:

On 03/04/2023 11:13, Chao Li wrote:

This problem is because the gcc-12 does not yet to support the option
'mno-explicit-reloc', this option is used to open the new reloaction
type for LoongArch, this new feature is very important for LoongArch,
because it can reduce the binary size and improve code execution
efficiency, so we turn it on when submitting the code to the EDK2 repo.

Is it possible to produce a _functional_ LoongArch64 EDK2 binary without
this option, even if the resulting binary is less efficient?

MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch
relocation type only, which I expect being the new type.  So I suspect
the answer is "no" because the edk2 pe loader isn't able to handle the
old relocation type(s).

take care,
  Gerd
--------------u3DaISOVAHtz3Qrrm9alBZjE--