From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lucky1.263xmail.com (lucky1.263xmail.com [211.157.147.135]) by mx.groups.io with SMTP id smtpd.web08.17558.1653553794350801009 for ; Thu, 26 May 2022 01:29:57 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: byosoft.net, ip: 211.157.147.135, mailfrom: byomail@byosoft.net) Received: from localhost (unknown [192.168.167.13]) by lucky1.263xmail.com (Postfix) with ESMTP id 79384C2E69 for ; Thu, 26 May 2022 16:29:46 +0800 (CST) X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-ADDR-CHECKED4: 1 bpcheck: 1 X-ANTISPAM-LEVEL: 2 X-ABS-CHECKED: 1 Received: from mail.byosoft.com.cn (unknown [58.240.74.242]) by smtp.263.net (postfix) whith ESMTP id P28208T139948715915008S1653553786903591_; Thu, 26 May 2022 16:29:47 +0800 (CST) X-IP-DOMAINF: 1 X-RL-SENDER: byomail@byosoft.net X-SENDER: byomail@byosoft.net X-LOGIN-NAME: byomail@byosoft.net X-FST-TO: devel@edk2.groups.io X-RCPT-COUNT: 1 X-LOCAL-RCPT-COUNT: 0 X-MUTI-DOMAIN-COUNT: 0 X-SENDER-IP: 58.240.74.242 X-ATTACHMENT-NUM: 0 X-UNIQUE-TAG: <62126b167507b421078476a933477529> X-System-Flag: 0 Received: from DESKTOPS6D0PVI ([101.224.116.119]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Thu, 26 May 2022 16:29:29 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-Originating-IP: 101.224.116.119 X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: , , "'Pedro Falcato'" , "'Gerd Hoffmann'" Cc: "'Ard Biesheuvel'" , "'Rebecca Cran'" , "'Ard Biesheuvel'" , "'Justen, Jordan L'" References: <19fda580-50da-302b-4c4e-0457fb28174b@quicinc.com> In-Reply-To: Subject: =?UTF-8?B?5Zue5aSNOiBbZWRrMi1kZXZlbF0gT3ZtZlBrZ1g2NCBkb2Vzbid0IGJ1aWxkIHdpdGggQ0xBTkczOCAoY2xhbmcgMTQuMC4zKSBOT09QVCAtIHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1lbWNweSc=?= Date: Thu, 26 May 2022 16:29:32 +0800 Message-ID: <000601d870da$b9684730$2c38d590$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGAf3sfI/u7uWN0H9WGpfCpbLa9kgIS4kKAAwfEnmsDYZ+r5AG/MVeIAjfPD5UB2gFAqwLfeCbpAXzUi+4BKWx5/QI6oFk0AZkVo/qtI39tEA== Sender: "gaoliming" Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01D8711D.C78E1F40" Content-Language: zh-cn ------=_NextPart_000_0007_01D8711D.C78E1F40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gerd: This issue is introduced by the commit 5f6ecaa398ba902f724be504663a0156c9e= 24570 OvmfPkg/VirtioGpuDxe: use GopQueryMode in GopSetMode from you. Can yo= u provide the hot fix for this stable tag 202205? This stable tag will be r= eleased on tomorrow.=20 =20 Thanks Liming =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io = =E4=BB=A3=E8=A1=A8 Yao, Jiewen =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B45=E6=9C=8826=E6=97=A5 8:= 06 =E6=94=B6=E4=BB=B6=E4=BA=BA: Pedro Falcato ; edk2-= devel-groups-io =E6=8A=84=E9=80=81: Ard Biesheuvel ; Rebecca Cran ; Ard Biesheuvel ; Justen, Jorda= n L ; Gerd Hoffmann =E4=B8=BB=E9=A2=98: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 = (clang 14.0.3) NOOPT - undefined reference to `memcpy' =20 Sounds good. :-) =20 From: Pedro Falcato >=20 Sent: Thursday, May 26, 2022 7:54 AM To: edk2-devel-groups-io >; Yao, Jiewen > Cc: Ard Biesheuvel >; Rebecca Cra= n >; Ard Biesheuvel= >; Justen, J= ordan L >; Ge= rd Hoffmann > Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0= .3) NOOPT - undefined reference to `memcpy' =20 Jiewen, =20 I'm definitely talking about the long term. Fixing this by just replacing i= t with CopyMem is definitely the right call for the stable tag. =20 Best regards, Pedro =20 On Thu, May 26, 2022 at 12:35 AM Yao, Jiewen > wrote: OK. Just want to clarify: =20 1. Are you discussing the solution now to resolve this issue, maybe in this= stable tag? 2. Or are you discussing the long term solution? =20 For me, I am focusing on #1 how to resolve this issue in this stable tag. =20 I am not talking long term solution #2 here. I think that need wider discus= sion in EDKII. =20 =20 =20 From: Pedro Falcato >=20 Sent: Thursday, May 26, 2022 7:31 AM To: edk2-devel-groups-io >; Yao, Jiewen > Cc: Ard Biesheuvel >; Rebecca Cra= n >; Ard Biesheuvel= >; Justen,= Jordan L >; = Gerd Hoffmann > Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0= .3) NOOPT - undefined reference to `memcpy' =20 Right. But as I said, GCC and Clang depend on 4 standard C library function= s. This behavior is documented, and has been stable for probably the past d= ecade or more. These are not intrinsics, but bog standard functions you can= totally redirect to the existing UEFI ones. I talked with the LLVM people = on IRC and they confirmed that that was essentially the reason why it used = a memcpy call. It's, in my opinion, OK to fix this particular issue if for example Visual = Studio does something fancier or requires actual intrinsics, but having sup= port for this would probably better solidify future compilation using GNU-l= ike toolchains. =20 Slightly offtopic, but I would dare to say that moving towards memcpy() and= others(versus CopyMem(), etc) would benefit EDK2 generated ASM quality as = the compiler has more of an idea of what you want to accomplish, if you pas= s -fbuiltin and let it assume your standard C library has the correct behav= ior; and indeed, GCC and Clang can, for instance, transform memcpy() calls = into rep movsb's or whatnot based on the CPU microarch it's compiling for, = or completely alias them if it sees you're doing it because of pointer alia= sing. =20 Thanks, Pedro =20 On Wed, May 25, 2022 at 11:58 PM Yao, Jiewen > wrote: =E2=80=9CDon=E2=80=99t use structure assignment=E2=80=9D is our best known = method to avoid compiler intrinsic in EDKII coding style since the project = is created. A third part library may include structure assignment, then we have to link= intrinsic. =20 If you only talk about memcpy, that is easy. But there might be others. The= problem is: We don=E2=80=99t know how many intrinsic should be there. It i= s fully based upon compiler. =20 Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not = done yet. =20 To me, using MemCopy is much easier to resolve this problem. =20 Thank you Yao Jiewen =20 From: devel@edk2.groups.io > On Behalf Of Pedro Falcato Sent: Thursday, May 26, 2022 6:48 AM To: Yao, Jiewen > Cc: Ard Biesheuvel >; edk2-devel-= groups-io >; Rebecca Cr= an >; Ard Biesheuve= l >; Justen= , Jordan L >;= Gerd Hoffmann > Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0= .3) NOOPT - undefined reference to `memcpy' =20 Is there a legitimate reason not to define memcpy? It'd be easier to do so = and comply to the compiler's requirements. =20 On Wed, 25 May 2022, 23:38 Yao, Jiewen, > wrote: Hi Would you please use CopyMem() for the structure assignment? VgpuGop->GopModeInfo =3D *GopModeInfo; =20 That is best known method to resolve memcpy symbol issue. =20 Thank you Yao Jiewen =20 =20 From: Pedro Falcato >=20 Sent: Thursday, May 26, 2022 1:01 AM To: Ard Biesheuvel > Cc: edk2-devel-groups-io >; Rebecca Cran >= ; Ard Biesheuvel >; Yao, Jiewen >;= Justen, Jordan L >; Gerd Hoffmann > Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0= .3) NOOPT - undefined reference to `memcpy' =20 On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel > wrote: On Wed, 25 May 2022 at 18:44, Pedro Falcato > wrote: > > > > On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel > wrote: >> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran > wrote: >> > >> > I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b >> > NOOPT` (with clang version 14.0.2) with the latest edk2 master >> > (07c0c2eb0a5970db614ebce1060fc79d6904bdfd): >> > >> > make: Nothing to be done for 'tbuild'. >> > /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value= : >> > 0x23 >> > /home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/Ovm= fPkg/VirtioGpuDxe/VirtioGpu/OUTPUT/VirtioGpuDxe.lib(Gop.obj): >> > in function `GopSetMode': >> > Gop.c:(.text.GopSetMode+0x418): undefined reference to `memcpy' >> >> Can you dump the object file to see where the memcpy() call is emitted? > > I think I found the smoking gun: https://github.com/tianocore/edk2/blob/9= 16f90baa547b3ebef8fa87c530e2f0c8e35e1e3/OvmfPkg/VirtioGpuDxe/Gop.c#L512 Indeed. We don't support struct assignment in Tianocore code, exactly for this reason. Note: We should think about providing some basic libc functions in base EDK= 2 as some are required by the clang/GCC compilers (see https://gcc.gnu.org/= onlinedocs/gcc/Standards.html, grep for memcpy or freestanding). Passing -ffreestanding would also be a good idea as to let the compiler kno= w it's dealing with a freestanding environment vs a hosted user-space one. =20 All the best, Pedro --=20 Pedro Falcato --=20 Pedro Falcato ------=_NextPart_000_0007_01D8711D.C78E1F40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Gerd:

=C2=A0T= his issue is introduced by the commit 5f6ecaa398ba902f724be504663a0156c9e24= 570 OvmfPkg/VirtioGpuDxe: use GopQueryMode in GopSetMode from you. Can you = provide the hot fix for this stable tag 202205? This stable tag will be rel= eased on tomorrow.

 =

Thanks

Liming

=E5=8F=91=E4=BB=B6= =E4=BA=BA: devel@edk2.groups.io <devel@edk2.groups= .io> =E4=BB=A3= =E8=A1=A8 Yao, Jiewen
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2022=E5=B9=B45=E6=9C=8826=E6=97=A5 = 8:06
=E6=94=B6=E4=BB=B6=E4=BA=BA: Pedro Falcato <pedro.falcato@gmail.com>; edk2-de= vel-groups-io <devel@edk2.groups.io>
=E6=8A=84=E9=80=81<= span lang=3DEN-US>: Ard Biesheuvel <ardb@k= ernel.org>; Rebecca Cran <quic_rcran@quicinc.com>; Ard Biesheuvel = <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@int= el.com>; Gerd Hoffmann <kraxel@redhat.com>
=E4=B8=BB= =E9=A2=98: Re: [edk2-devel= ] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined re= ference to `memcpy'

 

<= span lang=3DEN-US>Sounds good. :-)

 

From: P= edro Falcato <pedro.falcato@g= mail.com>
Sent: Thursday, May 26, 2022 7:54 AM
To:<= /b> edk2-devel-groups-io <devel@= edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: Ard Biesheuvel <ardb@kernel.org>; Rebecca Cran <quic_rcran@quicinc.com>; Ard Bi= esheuvel <ardb+tianocore@ke= rnel.org>; Justen, Jordan L <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [e= dk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - und= efined reference to `memcpy'

 

Jiewen,

 

I'm definitely talking about the l= ong term. Fixing this by just replacing it with CopyMem is definitely the r= ight call for the stable tag.

 

Best regards,

Pedro

 

=

On Thu, May 26, 2022 at 1= 2:35 AM Yao, Jiewen <jiewen.yao@= intel.com> wrote:

OK. Just want to clarify:

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

  1. Are you discussing the solution now to re= solve this issue, maybe in this stable tag?
  2. Or are you discussing the long term solution?<= /o:p>

 

For me, I am focusing on #1 how to resolve this = issue in this stable tag.

=  

I am not talking long= term solution #2 here. I think that need wider discussion in EDKII.

 

 

=  

From: Pedro = Falcato <pe= dro.falcato@gmail.com>
Sent: Thursday, May 26, 2022 7:31 = AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com<= /a>>
Cc: Ard Biesheuvel <ardb@kernel.org>; Rebecca Cran <quic_rcran@quicinc.com>= ;; Ard Biesheuvel <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@int= el.com>; Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel]= OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined ref= erence to `memcpy'

 

Right. B= ut as I said, GCC and Clang depend on 4 standard C library functions. This = behavior is documented, and has been stable for probably the past decade or= more. These are not intrinsics, but bog standard functions you can totally= redirect to the existing UEFI ones. I talked with the LLVM people on IRC a= nd they confirmed that that was essentially the reason why it used a memcpy= call.

It's,= in my opinion, OK to fix this particular issue if for example Visual Studi= o does something fancier or requires actual intrinsics, but having support = for this would probably better solidify future compilation using GNU-like t= oolchains.

=  

Slightly o= fftopic, but I would dare to say that moving towards memcpy() and others(ve= rsus CopyMem(), etc) would benefit EDK2 generated ASM quality as the compil= er has more of an idea of what you want to accomplish, if you pass -fbuilti= n and let it assume your standard C library has the correct behavior; and i= ndeed, GCC and Clang can, for instance, transform memcpy() calls into rep m= ovsb's or whatnot based on the CPU microarch it's compiling for, or complet= ely alias them if it sees you're doing it because of pointer aliasing.=

 

Thanks,

Pedro

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

On Wed, May 25, 2022 at 11:58 PM Yao, Jiewen <jiewen.yao@intel.com> = wrote:

=E2=80=9CDon=E2=80=99t use structure assignment=E2=80=9D is our best = known method to avoid compiler intrinsic in EDKII coding style since the pr= oject is created.

A third pa= rt library may include structure assignment, then we have to link intrinsic= .

 

If you only talk about memcpy, that is easy. Bu= t there might be others. The problem is: We don=E2=80=99t know how many int= rinsic should be there. It is fully based upon compiler.<= /p>

 

Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But i= t is not done yet.

 

To me, using MemCopy is much e= asier to resolve this problem.

 

Thank you

Yao Jiewen

 

From: devel@edk2.gro= ups.io <de= vel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Thursday, May 26, 2022 6:48 AM
To: Yao, Jiewen <jiewen.yao@intel.com><= br>Cc: Ard Biesheuvel <ardb@kernel.org>; edk2-devel-groups-io <devel@edk2.groups.io>; = Rebecca Cran <quic_rcran@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>= ;; Justen, Jordan L <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
<= b>Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clan= g 14.0.3) NOOPT - undefined reference to `memcpy'

 

<= span lang=3DEN-US>Is there a legitimate reason not to define memcpy? It'd b= e easier to do so and comply to the compiler's requirements.

 

On Wed, 25 May 2022, 23:38 Yao, Jiewen, <jiewen.yao@intel.com= > wrote:

Hi

Would you = please use CopyMem() for the structure assignment?

VgpuGop->GopM= odeInfo  =3D *GopModeInfo;

 <= o:p>

That is best known method to= resolve memcpy symbol issue.

 

Thank you

= Yao Jiewen

 

 <= /o:p>

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Bie= sheuvel <ardb@kerne= l.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Rebecca C= ran <quic_rc= ran@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao, J= iewen <jiewen.= yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gerd Hof= fmann <kraxel@red= hat.com>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't buil= d with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'<= /o:p>

 

On Wed, May 25, 2022 at 5:45 PM Ard B= iesheuvel <ardb@ker= nel.org> wrote:

On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com>= ; wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ar= d Biesheuvel <ardb@= kernel.org> wrote:
>>
>> On Wed, 25 May 2022 at 17= :08, Rebecca Cran <quic_rcran@quicinc.com> wrote:
>> >
>> &= gt; I noticed OvmfPkg/OvmfPkgX64.dsc doesn't build with `-t CLANG38 -b
&= gt;> > NOOPT` (with clang version 14.0.2) with the latest edk2 master=
>> > (07c0c2eb0a5970db614ebce1060fc79d6904bdfd):
>> &= gt;
>> > make: Nothing to be done for 'tbuild'.
>> >= ; /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value:>> > 0x23
>> > /home/bcran/src/upstream/uefi/edk2/Bu= ild/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu/OUTPUT/VirtioG= puDxe.lib(Gop.obj):
>> > in function `GopSetMode':
>> = > Gop.c:(.text.GopSetMode+0x418): undefined reference to `memcpy'
>= ;>
>> Can you dump the object file to see where the memcpy() ca= ll is emitted?
>
> I think I found the smoking gun: https://github.com/= tianocore/edk2/blob/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/OvmfPkg/Virtio= GpuDxe/Gop.c#L512

Indeed. We don't support struct assignment in = Tianocore code, exactly
for this reason.

Note: We should think about providi= ng some basic libc functions in base EDK2 as some are required by the clang= /GCC compilers (see https://gcc.gnu.org/onlinedocs/gcc/Standards.html<= /a>, grep for memcpy or freestanding).



--

<= /blockquote>


<= br>--

------=_NextPart_000_0007_01D8711D.C78E1F40--