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

[Pedro Falcato]

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 at 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 at edk2.groups.io <devel at edk2.groups.io> * On Behalf Of *Pedro
> Falcato
> *Sent:* Thursday, May 26, 2022 6:48 AM
> *To:* Yao, Jiewen <jiewen.yao at intel.com>
> *Cc:* Ard Biesheuvel <ardb at kernel.org>; edk2-devel-groups-io <
> devel at edk2.groups.io>; Rebecca Cran <quic_rcran at quicinc.com>; Ard
> Biesheuvel <ardb+tianocore at kernel.org>; Justen, Jordan L <
> jordan.l.justen at intel.com>; Gerd Hoffmann <kraxel at 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 at 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 at gmail.com>
> *Sent:* Thursday, May 26, 2022 1:01 AM
> *To:* Ard Biesheuvel <ardb at kernel.org>
> *Cc:* edk2-devel-groups-io <devel at edk2.groups.io>; Rebecca Cran <
> quic_rcran at quicinc.com>; Ard Biesheuvel <ardb+tianocore at kernel.org>; Yao,
> Jiewen <jiewen.yao at intel.com>; Justen, Jordan L <jordan.l.justen at intel.com>;
> Gerd Hoffmann <kraxel at 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 at kernel.org> wrote:
>
> On Wed, 25 May 2022 at 18:44, Pedro Falcato <pedro.falcato at gmail.com>
> wrote:
> >
> >
> >
> > On Wed, May 25, 2022 at 4:50 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> >>
> >> On Wed, 25 May 2022 at 17:08, Rebecca Cran <quic_rcran at 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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90021): https://edk2.groups.io/g/devel/message/90021
Mute This Topic: https://groups.io/mt/91335000/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20220526/d5667655/attachment.htm>