public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Pedro Falcato" <pedro.falcato@gmail.com>
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'
Date: Wed, 25 May 2022 23:48:15 +0100	[thread overview]
Message-ID: <CAKbZUD2_ZKJ1BRpPK9N4JPHctKOtvtmT2kyoxWNWWdFKS-ekig@mail.gmail.com> (raw)
In-Reply-To: <MW4PR11MB5872D671FD5353E426790BF98CD69@MW4PR11MB5872.namprd11.prod.outlook.com>

[-- 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 --]

  reply	other threads:[~2022-05-25 22:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25 15:08 OvmfPkgX64 doesn't build with CLANG38 (clang 14.0.3) NOOPT - undefined reference to `memcpy' Rebecca Cran
2022-05-25 15:50 ` Ard Biesheuvel
2022-05-25 16:43   ` [edk2-devel] " Pedro Falcato
2022-05-25 16:45     ` Ard Biesheuvel
2022-05-25 17:01       ` Pedro Falcato
2022-05-25 22:38         ` Yao, Jiewen
2022-05-25 22:48           ` Pedro Falcato [this message]
2022-05-25 22:58             ` Yao, Jiewen
2022-05-25 23:31               ` Pedro Falcato
2022-05-25 23:35                 ` Yao, Jiewen
2022-05-25 23:54                   ` Pedro Falcato
2022-05-26  0:05                     ` Yao, Jiewen
2022-05-26  8:29                       ` 回复: " gaoliming
2022-05-25 16:57     ` Rebecca Cran
2022-05-27  5:52   ` 回复: " gaoliming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKbZUD2_ZKJ1BRpPK9N4JPHctKOtvtmT2kyoxWNWWdFKS-ekig@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox