Re: On integrating LoongArch EDK2 firmware into QEMU build process

Re: On integrating LoongArch EDK2 firmware into QEMU build process

[maobibo]

Cc to Chao Li who is maintainer of edk2 about LoongArch support.

Hi Chao, 

Fedora38 is used to build edk2 binary in qemu CI, cross gcc-12 is
integrated on Fedora38. There is one issue when gcc-12 is used to
build edk2 loongarch like this:
> ... but when trying to use them to compile the loongarch firmware gcc
> throws errors:
>
> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-reloc

what is your option about this issue?

Regards
Bibo, Mao

在 2023/4/1 13:11, maobibo 写道:
> 
> 
> On 2023/3/31 20:12, Gerd Hoffmann wrote:
>> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>>> Xuerui,
>>>
>>> Thanks for your mail, it is a good suggestion. Now we are planing to
>>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>>> repo. Only that process is somwhat slow since lacking of hands,
>>> however we are doing this.
>>
>> Good, so I think it makes sense for qemu to just wait for that to
>> happen.
>>
>> Related question:  What are the requirements to build the firmware?
>> Fedora 38 ships cross compiler packages ...
>>
>>    binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>>    gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
>>
>> ... but when trying to use them to compile the loongarch firmware gcc
>> throws errors:
>>
>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
>>
>> I suspect gcc-12 is just too old?
> There is a little different about relocation between gcc-12 and gcc-13 on LoongArch, gcc-13 is required for edk2 compiler now.
> 
> However I think it is actually is one issue if gcc-12 can not be used and gcc-12 is popular latest compiler for all architectures. We will solve this problem.
> 
> Regards
> Bibo, Mao
> 
> 
>>
>> take care,
>>    Gerd
>>
> 

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Chao Li]

[-- Attachment #1: Type: text/plain, Size: 3141 bytes --]

Hi Bibo,

Thanks for Cc to me.


Hi Gerd,

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.

gcc-13 will support this new feature, so we expect this issue to be 
resolved when using gcc-13, which may be released at this month.

If Fedora38 does not plan to use gcc-13 now, I suggest that CI can 
download a LoongArch cross gcc-13 when creating a docker image, just 
like EDK2 CI process. You can refer following link for more information: 
https://github.com/tianocore/containers/blob/main/Fedora-37/Dockerfile . 
EDK2 CI uses Fedora35 and Fedora37 docker images for LoongArch,  they 
will download a LoongArch cross gcc-13 when the CI targets is LoongArch.

We are really sorry about that, I think this solution will make more 
work for you, but I think it is the best way for now, and I believe it 
will be solved when Fedora uses gcc-13 in the future.


Thanks,
Chao
在 2023/4/3 16:51, maobibo 写道:
> Cc to Chao Li who is maintainer of edk2 about LoongArch support.
>
> Hi Chao,
>
> Fedora38 is used to build edk2 binary in qemu CI, cross gcc-12 is
> integrated on Fedora38. There is one issue when gcc-12 is used to
> build edk2 loongarch like this:
>> ... but when trying to use them to compile the loongarch firmware gcc
>> throws errors:
>>
>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-reloc
> what is your option about this issue?
>
> Regards
> Bibo, Mao
>
> 在 2023/4/1 13:11, maobibo 写道:
>>
>> On 2023/3/31 20:12, Gerd Hoffmann wrote:
>>> On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote:
>>>> Xuerui,
>>>>
>>>> Thanks for your mail, it is a good suggestion. Now we are planing to
>>>> move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi
>>>> bios supporting LoongArch can be auto compiled and uploaded to qemu
>>>> repo. Only that process is somwhat slow since lacking of hands,
>>>> however we are doing this.
>>> Good, so I think it makes sense for qemu to just wait for that to
>>> happen.
>>>
>>> Related question:  What are the requirements to build the firmware?
>>> Fedora 38 ships cross compiler packages ...
>>>
>>>     binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64
>>>     gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64
>>>
>>> ... but when trying to use them to compile the loongarch firmware gcc
>>> throws errors:
>>>
>>> loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’
>>>
>>> I suspect gcc-12 is just too old?
>> There is a little different about relocation between gcc-12 and gcc-13 on LoongArch, gcc-13 is required for edk2 compiler now.
>>
>> However I think it is actually is one issue if gcc-12 can not be used and gcc-12 is popular latest compiler for all architectures. We will solve this problem.
>>
>> Regards
>> Bibo, Mao
>>
>>
>>> take care,
>>>     Gerd
>>>
>
>
> 
>

[-- Attachment #2: Type: text/html, Size: 4867 bytes --]

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Michael Brown]

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?

(I'm the person who updated Fedora's binutils and cross-gcc packages to 
ensure that LoongArch64 was supported in Fedora 38, and this 
-mno-explicit-relocs issue is also currently blocking me from merging 
LoongArch64 support into iPXE.)

Thanks,

Michael

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[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

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Chao Li]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

在 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
>
>
>
> 
>

[-- Attachment #2: Type: text/html, Size: 4046 bytes --]

Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process

[Gerd Hoffmann]

On Mon, Apr 03, 2023 at 06:13:41PM +0800, Chao Li wrote:
> Hi Bibo,
> 
> gcc-13 will support this new feature, so we expect this issue to be resolved
> when using gcc-13, which may be released at this month.
> 
> If Fedora38 does not plan to use gcc-13 now, I suggest that CI can download
> a LoongArch cross gcc-13 when creating a docker image, just like EDK2 CI
> process. You can refer following link for more information:

The non-cross gcc already is at 13.  Fedora builds the distro with
pre-release gcc so gcc gets some serious real-world testing before
release.

The cross compilers lagging behind a bit, not sure whenever there is
some actual problem or whenever maintainers are just waiting for the
final gcc-13 release.

> https://github.com/tianocore/containers/blob/main/Fedora-37/Dockerfile .
> EDK2 CI uses Fedora35 and Fedora37 docker images for LoongArch,  they will
> download a LoongArch cross gcc-13 when the CI targets is LoongArch.

While that works as temporary stopgap for edk2 CI it is a non-starter
for fedora distro builds.  Any builds must be done using compilers
shipped by fedora.  So, fedora shipping edk2-loongarch (or
ipxe-loongarch) packages is blocked by this.

> We are really sorry about that, I think this solution will make more work
> for you, but I think it is the best way for now, and I believe it will be
> solved when Fedora uses gcc-13 in the future.

I'll go just wait for gcc-13 cross compilers land in fedora then.

take care,
  Gerd