From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: devel@edk2.groups.io, "Kinney,
Michael D" <michael.d.kinney@intel.com>,
"Lin, Benny" <benny.lin@intel.com>,
"Gao, Liming" <gaoliming@byosoft.com.cn>,
"Liu, Zhiguang" <zhiguang.liu@intel.com>,
Sean Brogan <sean.brogan@microsoft.com>,
Michael Kubacki <mikuback@linux.microsoft.com>,
Leif Lindholm <llindhol@qti.qualcomm.com>
Subject: Re: [edk2-devel] [PATCH 0/2] Support FDT library.
Date: Fri, 31 Mar 2023 13:18:58 +0100 [thread overview]
Message-ID: <CAKbZUD02eSjAGqh6uiwsJdLMb097P1vY4z6qvZaQ0u01T5swJA@mail.gmail.com> (raw)
In-Reply-To: <ffd5ohlve563y6tpjqvmgahguefhaok5t254kwhjeo5g3w6kjv@vuska3losaxy>
On Fri, Mar 31, 2023 at 12:39 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Hi,
>
> > > Getting down to one libc wrapper would be great. Do you want to provide a proposed
> > > implementation? That could be handled as a separate task.
> >
> > I would like it if we could stop contributing to that problem. We very
> > much *know* there is a problem with both libc fragments and compiler
> > intrinsic fragments all over edk2.
>
> I'd suggest to start with what we already have in the tree. Which is
> (not fully sure the list is actually complete):
>
> - CryptoPkg/Library/Include/ carrying the bits needed to make openssl
> compile, and
> - CryptoPkg/Library/IntrinsicLib (again, for openssl, mostly IA32, some
> X64) and,
> - ArmPkg/Library/CompilerIntrinsicsLib (mostly ARM, some AARCH64).
>
> Can we move that over to MdePkg so everyone can easily share it instead
> of adding more copies of the same to the tree?
Yes please. The problem with starting with what's in the tree is that
it's very messy and sometimes of super dubious quality.
For instance, on CryptoPkg there's the same lack of rigour in the
headers and CrtWrapper.c that I would rather avoid, as to make this a
relatively proper thing
(did you know if OpenSSL strcpy's over 4KiB it silently fails?).
> I have an old branch gathering dust doing that for the intrinsics, I can
> try rebasing it to latest master next week ...
Yes please! I did think about bringing in compiler-rt from LLVM for
high quality relatively self-contained intrinsics a good while ago.
There's the open question that GCC and clang require intrinsics and a
very small set of libc string functions to properly generate code.
Could BaseTools implicitly link this in? If we do it correctly,
there's no reason why the binaries would grow beyond what it requires
from the intrinsics set.
And I actually did see problems with lacking memcpy when trying out
tree-wide GCC12/clang -ftrivial-auto-var-init...
Anyway, if you want help with this or want to sync up efforts, do ping
me off-list :)
--
Pedro
next prev parent reply other threads:[~2023-03-31 12:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 16:52 [PATCH 0/2] Support FDT library benny.lin
2023-03-30 16:52 ` [PATCH 1/2] MdePkg: " Benny Lin
2023-03-30 17:01 ` Michael D Kinney
2023-03-30 23:19 ` [edk2-devel] " Pedro Falcato
2023-04-12 16:59 ` Benny Lin
2023-03-30 16:52 ` [PATCH 2/2] .pytool: " Benny Lin
2023-03-30 21:50 ` [edk2-devel] [PATCH 0/2] " Pedro Falcato
2023-03-30 22:59 ` Michael D Kinney
2023-03-30 23:26 ` Pedro Falcato
2023-03-30 23:32 ` Michael D Kinney
2023-03-31 2:35 ` Pedro Falcato
2023-03-31 11:39 ` Gerd Hoffmann
2023-03-31 12:18 ` Pedro Falcato [this message]
2023-03-31 12:17 ` Leif Lindholm
2023-03-31 12:12 ` Leif Lindholm
2023-04-01 1:29 ` Andrei Warkentin
2023-04-06 16:33 ` Sheng Lean Tan
2023-04-07 13:23 ` Pedro Falcato
2023-04-07 22:35 ` Andrei Warkentin
2023-04-07 23:04 ` Michael D Kinney
2023-04-11 13:19 ` Sheng Lean Tan
2023-04-11 16:07 ` Pedro Falcato
2023-04-11 17:00 ` Michael D Kinney
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=CAKbZUD02eSjAGqh6uiwsJdLMb097P1vY4z6qvZaQ0u01T5swJA@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