OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Rebecca Cran]

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/OvmfPkg/VirtioGpuDxe/VirtioGpu/OUTPUT/VirtioGpuDxe.lib(Gop.obj): 
in function `GopSetMode':
Gop.c:(.text.GopSetMode+0x418): undefined reference to `memcpy'
Building ... 
/home/bcran/src/upstream/uefi/edk2/OvmfPkg/PlatformPei/PlatformPei.inf 
[X64]
clang-14.0: error: linker command failed with exit code 1 (use -v to see 
invocation)
make: Nothing to be done for 'tbuild'.
make: *** [GNUmakefile:358: 
/home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu/DEBUG/VirtioGpuDxe.dll] 
Error 1


build.py...
: error 7000: Failed to execute command
        make tbuild 
[/home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu]


build.py...
: error F002: Failed to build module
        /home/bcran/src/upstream/uefi/edk2/OvmfPkg/VirtioGpuDxe/VirtioGpu.inf [X64, CLANG38, NOOPT]

- Failed -
Build end time: 09:03:38, May.25 2022
Build total time: 00:00:07


-- 
Rebecca Cran

Re: OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Ard Biesheuvel]

On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com> 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/OvmfPkg/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?


> Building ...
> /home/bcran/src/upstream/uefi/edk2/OvmfPkg/PlatformPei/PlatformPei.inf
> [X64]
> clang-14.0: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make: Nothing to be done for 'tbuild'.
> make: *** [GNUmakefile:358:
> /home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu/DEBUG/VirtioGpuDxe.dll]
> Error 1
>
>
> build.py...
> : error 7000: Failed to execute command
>         make tbuild
> [/home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu]
>
>
> build.py...
> : error F002: Failed to build module
>         /home/bcran/src/upstream/uefi/edk2/OvmfPkg/VirtioGpuDxe/VirtioGpu.inf [X64, CLANG38, NOOPT]
>
> - Failed -
> Build end time: 09:03:38, May.25 2022
> Build total time: 00:00:07
>
>
> --
> Rebecca Cran

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Pedro Falcato]

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

On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org> wrote:

> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/OvmfPkg/VirtioGpuDxe/Gop.c#L512

>
>
> > Building ...
> > /home/bcran/src/upstream/uefi/edk2/OvmfPkg/PlatformPei/PlatformPei.inf
> > [X64]
> > clang-14.0: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > make: Nothing to be done for 'tbuild'.
> > make: *** [GNUmakefile:358:
> >
> /home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu/DEBUG/VirtioGpuDxe.dll]
> > Error 1
> >
> >
> > build.py...
> > : error 7000: Failed to execute command
> >         make tbuild
> >
> [/home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/OvmfPkg/VirtioGpuDxe/VirtioGpu]
> >
> >
> > build.py...
> > : error F002: Failed to build module
> >
>  /home/bcran/src/upstream/uefi/edk2/OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> [X64, CLANG38, NOOPT]
> >
> > - Failed -
> > Build end time: 09:03:38, May.25 2022
> > Build total time: 00:00:07
> >
> >
> > --
> > Rebecca Cran
>

A very clear issue I'm seeing (in tools_def) is that no GCC-like toolchains
pass -ffreestanding and that may be causing issues. I'll try to reproduce
it on my end and see if it's a bug in LLVM.

>
>
> 
>
>
>

-- 
Pedro Falcato

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Ard Biesheuvel]

On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/OvmfPkg/VirtioGpuDxe/Gop.c#L512

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Pedro Falcato]

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

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.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 Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com>
> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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
EDK2 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
know it's dealing with a freestanding environment vs a hosted user-space
one.

All the best,
Pedro

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Yao, Jiewen]

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

Hi
Would you please use CopyMem() for the structure assignment?
VgpuGop->GopModeInfo  = *GopModeInfo;

That is best known method to resolve memcpy symbol issue.

Thank you
Yao Jiewen


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

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>> wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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 EDK2 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 know it's dealing with a freestanding environment vs a hosted user-space one.

All the best,
Pedro

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Pedro Falcato]

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

Is there a legitimate reason not to define memcpy? It'd be 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->GopModeInfo  = *GopModeInfo;
>
>
>
> That is best known method to resolve memcpy symbol issue.
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
>
>
> *From:* Pedro Falcato <pedro.falcato@gmail.com>
> *Sent:* Thursday, May 26, 2022 1:01 AM
> *To:* Ard Biesheuvel <ardb@kernel.org>
> *Cc:* edk2-devel-groups-io <devel@edk2.groups.io>; Rebecca Cran <
> quic_rcran@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao,
> Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Gerd Hoffmann <kraxel@redhat.com>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.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 Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com>
> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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
> EDK2 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
> know it's dealing with a freestanding environment vs a hosted user-space
> one.
>
>
>
> All the best,
>
> Pedro
>

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Yao, Jiewen]

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

“Don’t use structure assignment” 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.

If you only talk about memcpy, that is easy. But there might be others. The problem is: We don’t know how many intrinsic should be there. It is fully based upon compiler.

Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not done yet.

To me, using MemCopy is much easier to resolve this problem.

Thank you
Yao Jiewen

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Thursday, May 26, 2022 6:48 AM
To: Yao, Jiewen <jiewen.yao@intel.com>
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>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

Is there a legitimate reason not to define memcpy? It'd be easier to do so and comply to the compiler's requirements.

On Wed, 25 May 2022, 23:38 Yao, Jiewen, <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
Hi
Would you please use CopyMem() for the structure assignment?
VgpuGop->GopModeInfo  = *GopModeInfo;

That is best known method to resolve memcpy symbol issue.

Thank you
Yao Jiewen


From: Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Cc: edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>>; Ard Biesheuvel <ardb+tianocore@kernel.org<mailto:ardb%2Btianocore@kernel.org>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>> wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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 EDK2 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 know it's dealing with a freestanding environment vs a hosted user-space one.

All the best,
Pedro


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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Pedro Falcato]

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

Right. But 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 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
support for this would probably better solidify future compilation using
GNU-like toolchains.

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
pass -fbuiltin and let it assume your standard C library has the correct
behavior; 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
aliasing.

Thanks,
Pedro

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

> “Don’t use structure assignment” 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.
>
>
>
> If you only talk about memcpy, that is easy. But there might be others.
> The problem is: We don’t know how many intrinsic should be there. It is
> fully based upon compiler.
>
>
>
> Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not
> done yet.
>
>
>
> To me, using MemCopy is much easier to resolve this problem.
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> * On Behalf Of *Pedro
> Falcato
> *Sent:* Thursday, May 26, 2022 6:48 AM
> *To:* Yao, Jiewen <jiewen.yao@intel.com>
> *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>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> Is there a legitimate reason not to define memcpy? It'd be 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->GopModeInfo  = *GopModeInfo;
>
>
>
> That is best known method to resolve memcpy symbol issue.
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
>
>
> *From:* Pedro Falcato <pedro.falcato@gmail.com>
> *Sent:* Thursday, May 26, 2022 1:01 AM
> *To:* Ard Biesheuvel <ardb@kernel.org>
> *Cc:* edk2-devel-groups-io <devel@edk2.groups.io>; Rebecca Cran <
> quic_rcran@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao,
> Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Gerd Hoffmann <kraxel@redhat.com>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.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 Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com>
> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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
> EDK2 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
> know it's dealing with a freestanding environment vs a hosted user-space
> one.
>
>
>
> All the best,
>
> Pedro
>
> 
>
>

-- 
Pedro Falcato

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Yao, Jiewen]

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

OK. Just want to clarify:


  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?

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 <pedro.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>
Cc: Ard Biesheuvel <ardb@kernel.org>; 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>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

Right. But 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 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 support for this would probably better solidify future compilation using GNU-like toolchains.

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 pass -fbuiltin and let it assume your standard C library has the correct behavior; 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 aliasing.

Thanks,
Pedro

On Wed, May 25, 2022 at 11:58 PM Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
“Don’t use structure assignment” 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.

If you only talk about memcpy, that is easy. But there might be others. The problem is: We don’t know how many intrinsic should be there. It is fully based upon compiler.

Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not done yet.

To me, using MemCopy is much easier to resolve this problem.

Thank you
Yao Jiewen

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

Is there a legitimate reason not to define memcpy? It'd be easier to do so and comply to the compiler's requirements.

On Wed, 25 May 2022, 23:38 Yao, Jiewen, <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
Hi
Would you please use CopyMem() for the structure assignment?
VgpuGop->GopModeInfo  = *GopModeInfo;

That is best known method to resolve memcpy symbol issue.

Thank you
Yao Jiewen


From: Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Cc: edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>>; Ard Biesheuvel <ardb+tianocore@kernel.org<mailto:ardb%2Btianocore@kernel.org>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>> wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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 EDK2 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 know it's dealing with a freestanding environment vs a hosted user-space one.

All the best,
Pedro



--
Pedro Falcato

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Pedro Falcato]

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

Jiewen,

I'm definitely talking about the long term. Fixing this by just replacing
it with CopyMem is definitely the right call for the stable tag.

Best regards,
Pedro

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

> OK. Just want to clarify:
>
>
>
>    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?
>
>
>
> 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 <pedro.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>
> *Cc:* Ard Biesheuvel <ardb@kernel.org>; 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>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> Right. But 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 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
> support for this would probably better solidify future compilation using
> GNU-like toolchains.
>
>
>
> 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
> pass -fbuiltin and let it assume your standard C library has the correct
> behavior; 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
> aliasing.
>
>
>
> Thanks,
>
> Pedro
>
>
>
> On Wed, May 25, 2022 at 11:58 PM Yao, Jiewen <jiewen.yao@intel.com> wrote:
>
> “Don’t use structure assignment” 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.
>
>
>
> If you only talk about memcpy, that is easy. But there might be others.
> The problem is: We don’t know how many intrinsic should be there. It is
> fully based upon compiler.
>
>
>
> Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not
> done yet.
>
>
>
> To me, using MemCopy is much easier to resolve this problem.
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of *Pedro
> Falcato
> *Sent:* Thursday, May 26, 2022 6:48 AM
> *To:* Yao, Jiewen <jiewen.yao@intel.com>
> *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>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> Is there a legitimate reason not to define memcpy? It'd be 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->GopModeInfo  = *GopModeInfo;
>
>
>
> That is best known method to resolve memcpy symbol issue.
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
>
>
> *From:* Pedro Falcato <pedro.falcato@gmail.com>
> *Sent:* Thursday, May 26, 2022 1:01 AM
> *To:* Ard Biesheuvel <ardb@kernel.org>
> *Cc:* edk2-devel-groups-io <devel@edk2.groups.io>; Rebecca Cran <
> quic_rcran@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao,
> Jiewen <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Gerd Hoffmann <kraxel@redhat.com>
> *Subject:* Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang
> 14.0.3) NOOPT - undefined reference to `memcpy'
>
>
>
> On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.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 Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com>
> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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
> EDK2 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
> know it's dealing with a freestanding environment vs a hosted user-space
> one.
>
>
>
> All the best,
>
> Pedro
>
>
>
> --
>
> Pedro Falcato
> 
>
>

-- 
Pedro Falcato

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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Yao, Jiewen]

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

Sounds good. :-)

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Thursday, May 26, 2022 7:54 AM
To: 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 Biesheuvel <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

Jiewen,

I'm definitely talking about the long term. Fixing this by just replacing it with CopyMem is definitely the right call for the stable tag.

Best regards,
Pedro

On Thu, May 26, 2022 at 12:35 AM Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
OK. Just want to clarify:


  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?

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 <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>
Sent: Thursday, May 26, 2022 7:31 AM
To: edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
Cc: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>; Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>>; Ard Biesheuvel <ardb+tianocore@kernel.org<mailto:ardb%2Btianocore@kernel.org>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

Right. But 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 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 support for this would probably better solidify future compilation using GNU-like toolchains.

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 pass -fbuiltin and let it assume your standard C library has the correct behavior; 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 aliasing.

Thanks,
Pedro

On Wed, May 25, 2022 at 11:58 PM Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
“Don’t use structure assignment” 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.

If you only talk about memcpy, that is easy. But there might be others. The problem is: We don’t know how many intrinsic should be there. It is fully based upon compiler.

Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not done yet.

To me, using MemCopy is much easier to resolve this problem.

Thank you
Yao Jiewen

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

Is there a legitimate reason not to define memcpy? It'd be easier to do so and comply to the compiler's requirements.

On Wed, 25 May 2022, 23:38 Yao, Jiewen, <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
Hi
Would you please use CopyMem() for the structure assignment?
VgpuGop->GopModeInfo  = *GopModeInfo;

That is best known method to resolve memcpy symbol issue.

Thank you
Yao Jiewen


From: Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Cc: edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>>; Ard Biesheuvel <ardb+tianocore@kernel.org<mailto:ardb%2Btianocore@kernel.org>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Gerd Hoffmann <kraxel@redhat.com<mailto:kraxel@redhat.com>>
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>> wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>> wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com<mailto:quic_rcran@quicinc.com>> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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 EDK2 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 know it's dealing with a freestanding environment vs a hosted user-space one.

All the best,
Pedro


--
Pedro Falcato



--
Pedro Falcato

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

回复: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[gaoliming]

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

Gerd:

 This issue is introduced by the commit 5f6ecaa398ba902f724be504663a0156c9e24570 OvmfPkg/VirtioGpuDxe: use GopQueryMode in GopSetMode from you. Can you provide the hot fix for this stable tag 202205? This stable tag will be released on tomorrow. 

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Yao, Jiewen
发送时间: 2022年5月26日 8:06
收件人: Pedro Falcato <pedro.falcato@gmail.com>; edk2-devel-groups-io <devel@edk2.groups.io>
抄送: Ard Biesheuvel <ardb@kernel.org>; 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>
主题: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

 

Sounds good. :-)

 

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

 

Jiewen,

 

I'm definitely talking about the long term. Fixing this by just replacing it with CopyMem is definitely the right call for the stable tag.

 

Best regards,

Pedro

 

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

OK. Just want to clarify:

 

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?

 

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 <pedro.falcato@gmail.com <mailto:pedro.falcato@gmail.com> > 
Sent: Thursday, May 26, 2022 7:31 AM
To: edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io> >; Yao, Jiewen <jiewen.yao@intel.com <mailto:jiewen.yao@intel.com> >
Cc: Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org> >; Rebecca Cran <quic_rcran@quicinc.com <mailto:quic_rcran@quicinc.com> >; Ard Biesheuvel <ardb+tianocore@kernel.org <mailto:ardb%2Btianocore@kernel.org> >; Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com> >; Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com> >
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

 

Right. But 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 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 support for this would probably better solidify future compilation using GNU-like toolchains.

 

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 pass -fbuiltin and let it assume your standard C library has the correct behavior; 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 aliasing.

 

Thanks,

Pedro

 

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

“Don’t use structure assignment” 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.

 

If you only talk about memcpy, that is easy. But there might be others. The problem is: We don’t know how many intrinsic should be there. It is fully based upon compiler.

 

Gerd proposed to move to intrinsic from cryptopkg to mdepkg. But it is not done yet.

 

To me, using MemCopy is much easier to resolve this problem.

 

Thank you

Yao Jiewen

 

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

 

Is there a legitimate reason not to define memcpy? It'd be easier to do so and comply to the compiler's requirements.

 

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

Hi

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

VgpuGop->GopModeInfo  = *GopModeInfo;

 

That is best known method to resolve memcpy symbol issue.

 

Thank you

Yao Jiewen

 

 

From: Pedro Falcato <pedro.falcato@gmail.com <mailto:pedro.falcato@gmail.com> > 
Sent: Thursday, May 26, 2022 1:01 AM
To: Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org> >
Cc: edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io> >; Rebecca Cran <quic_rcran@quicinc.com <mailto:quic_rcran@quicinc.com> >; Ard Biesheuvel <ardb+tianocore@kernel.org <mailto:ardb%2Btianocore@kernel.org> >; Yao, Jiewen <jiewen.yao@intel.com <mailto:jiewen.yao@intel.com> >; Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com> >; Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com> >
Subject: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

 

On Wed, May 25, 2022 at 5:45 PM Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org> > wrote:

On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato@gmail.com <mailto:pedro.falcato@gmail.com> > wrote:
>
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org> > wrote:
>>
>> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com <mailto:quic_rcran@quicinc.com> > 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/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 EDK2 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 know it's dealing with a freestanding environment vs a hosted user-space one.

 

All the best,

Pedro



-- 

Pedro Falcato



-- 

Pedro Falcato




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

Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[Rebecca Cran]

On 5/25/22 10:43, Pedro Falcato wrote:
>
>
> On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
>     On Wed, 25 May 2022 at 17:08, Rebecca Cran
>     <quic_rcran@quicinc.com> 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/OvmfPkg/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/916f90baa547b3ebef8fa87c530e2f0c8e35e1e3/OvmfPkg/VirtioGpuDxe/Gop.c#L512

Ah, thanks! I've just sent out another email this time about building 
with the XCODE5 toolchain and _AsmRelocateApMailBoxLoopStart not being 
defined.

-- 
Rebecca Cran

回复: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy'

[gaoliming]

Ard:
  Jiewen has mentioned the issues caused by the structure assignment. Below structure assignment is required to be replaced by CopyMem.

  VgpuGop->GopModeInfo  = *GopModeInfo;

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Ard
> Biesheuvel
> 发送时间: 2022年5月25日 23:50
> 收件人: Rebecca Cran <quic_rcran@quicinc.com>
> 抄送: edk2-devel-groups-io <devel@edk2.groups.io>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Jiewen Yao <jiewen.yao@intel.com>; Jordan
> Justen <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
> 主题: Re: [edk2-devel] OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3)
> NOOPT - undefined reference to `memcpy'
> 
> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran@quicinc.com>
> 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/X6
> 4/OvmfPkg/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?
> 
> 
> > Building ...
> >
> /home/bcran/src/upstream/uefi/edk2/OvmfPkg/PlatformPei/PlatformPei.inf
> > [X64]
> > clang-14.0: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > make: Nothing to be done for 'tbuild'.
> > make: *** [GNUmakefile:358:
> >
> /home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X6
> 4/OvmfPkg/VirtioGpuDxe/VirtioGpu/DEBUG/VirtioGpuDxe.dll]
> > Error 1
> >
> >
> > build.py...
> > : error 7000: Failed to execute command
> >         make tbuild
> >
> [/home/bcran/src/upstream/uefi/edk2/Build/OvmfX64/NOOPT_CLANG38/X
> 64/OvmfPkg/VirtioGpuDxe/VirtioGpu]
> >
> >
> > build.py...
> > : error F002: Failed to build module
> >
> /home/bcran/src/upstream/uefi/edk2/OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> [X64, CLANG38, NOOPT]
> >
> > - Failed -
> > Build end time: 09:03:38, May.25 2022
> > Build total time: 00:00:07
> >
> >
> > --
> > Rebecca Cran
> 
> 
> 
>