From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (EUR04-VI1-obe.outbound.protection.outlook.com [40.92.75.76]) by mx.groups.io with SMTP id smtpd.web08.308.1643386348157536474 for ; Fri, 28 Jan 2022 08:12:29 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=XZrLFGQO; spf=pass (domain: outlook.com, ip: 40.92.75.76, mailfrom: kilian_kegel@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=emwY6CM0uXLITtHM9zdDSZ+Yeg2cwa47Itee4ihb4qiz4plLo6K01OV8qXwmmyXn+TA4s4i6pe8PjK+54WiWKs85Gdcxy0sZ49RTn05U83eWmzEOFtrNWS2LoErZBvoFNfWjnGNJt5AzP+TKuOQtgg06bKSx1D61pH9OFuslvx4vwbUqF5qdqNP8lh8Wva0PAIw3CH66Hg0EpWKjK3m+j0xUFNYb1BogiYTECA5CHQ6pF5uaNRpDU2Q5umPAAxIkf4JohLwAYBIKcgOlGNR7fvONsrpRan64HUI4z0XWXRpcTEx7Uxvvw92pdXn2SloJNuS7i1BiAG23/mnqfqQzEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2jIBCdYGmfYuQLTlAyXBbBkHJuifCNlMooPVK6isPsk=; b=BBTqHY9FrVFJ7HEDTIuQvSYP5y7x+JF9LYjmUynYZeOf9TJXe9OhxKU846oyCLvhWljU+MGTwIzesGkbvtopynOqoZASkrleh9tJkXsGU14IG5eW2xILJ4xmYBNCfAw7aD2CQs4DHpXnSkvbXEjoRI/xg6M23P9G3H3H6Qmwx3YNEiEYESvT0dDwk6JmAZOhZWWMOsph3x95WwjfWOMKILA94dcNI+E22qJFpThc3DHaaxCInwzZv3N0+E1eIJPUhAcuvEopKVebHNo3KmIGdoD3hta6JdWxQG3K9qHt930/82iQUlKdZyzpVyJnVmxIy77ZxjsQtfmEKvE2FMMJhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2jIBCdYGmfYuQLTlAyXBbBkHJuifCNlMooPVK6isPsk=; b=XZrLFGQO3ot+bWWitOtKco+hd1iV6d79qxuvuIP+YpuLQmZSQtwsDuUl76lvO8ghUj40xv8q0rPRVpQwcm3NiNEN8tfhn0RX9q66csJTw93NZ+Vh+uO7PKWQHQF2u3HK9DiUX4nHJsTT4Hr5nK0MO7nR1YJkVCBKm3aXPWkwfTK2UamZ26mCB+F8Lok7r57vR9vJe/OFYTVW4oPPGjPMzX1ky0Jm1DA/3El1lWFgiQ+HOIUx9UkT5nB7Cme6m2RmlCCG7NJ2W8bsy5dCrHwUbpRLE3GBkWtn2UfDhWRRujXh+iLGHhWgAXEByJNOsdm5cmeST7dJChSGXUUPOiCZ+g== Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d0::21) by DB9P190MB1132.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:227::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.18; Fri, 28 Jan 2022 16:12:25 +0000 Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::88b4:c09b:8790:e490]) by AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::88b4:c09b:8790:e490%4]) with mapi id 15.20.4930.019; Fri, 28 Jan 2022 16:12:25 +0000 From: "Kilian Kegel" To: "devel@edk2.groups.io" , "pedro.falcato@gmail.com" , "kraxel@redhat.com" Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Thread-Topic: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Thread-Index: AQHYFFBpsMFffkAnZkCifq0hDhB+uKx4l7MAgAACYuw= Date: Fri, 28 Jan 2022 16:12:25 +0000 Message-ID: References: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tmn: [KpryS6KvQk6UMOTIUBprManm7CedUX8Y4giSm4KTzKTePLrOQ/CjVhGANyWsp1vC] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1904b7b5-fb89-419c-56a6-08d9e278f950 x-ms-traffictypediagnostic: DB9P190MB1132:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3SI9sFDY7XqWUvA8C3cftv7k/wrPPbfcGLWkAYH7Dle11qgb7cDcoLan6GYstbDNXXr7EmoEudfRO8oDQH7kKnxqXB3eqQcz+yu5//TBnah+eRjP0bHDatwcFKudydU0eR0gjEmdy8OJwTowSVZqNuFI1QP8QHZgmzDnnJry1ognZL+evWBtRp/Czxx9PJ7Y1zwhzah3B4lkz9mMHdx/7XdV6sJ9IQj78uZrYvE85CUJ4WnSKqCToRET+itpIfQ5sk1DlJ0Rtc87sgFaTwNGwGLx+2+iLobM67PVnzGNpv8n5fF02gzQ5fmFcgumoH6GTguas1PHogCcgOdYG7d2+fOkLSh+LU0OSvgIV1BsVy9w185sNV9P5GfZRF036741yfW7VxqEyeV+9U8F+TJgHbI9o7AbC4w9yETv4uWw000+CyT8i6vifh44eTXAy605CiKE38cocUcpeWvO5ffy1+3SWlgKFv1ipCP5d1ylZwdixZ1nEcpM3flLoAfjy+Czn1J69xuET6xNCbPMAQfLBK4PjFwq9QX27QmsTJx8XE7z6VGyEjDzt+1KQQQjIhyGDrcvo1ga21dnZd9XHn6V3mOGUP24pWNs+LGYCeEIBSyT4KTj/KG5n9u/XUlFheuwVY1swlsai6+L4ZUJyi6MIVGUMcXADbjVG3p/gZ9iwXw= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2usjU+qh0nRoPdd6R19DcTzyTazvdfQ8OqblIrlyEBAFLR2ccuRffxYW?= =?Windows-1252?Q?uyuOtHVK8pgoaFYNMJXQdcsQkyFFyjIL6suORCh4PVgiQUiPLsq57b8/?= =?Windows-1252?Q?2BUU05BfFwHBieTv75NwoApDifGBT9ctqOXEQpzdQ7QY5quDkhdNDnqI?= =?Windows-1252?Q?kCYeA0sGbkkSi0dyXBY40wiFjj2wZ6eCHvdRDrSFH7/s+nI43Jf4/AwK?= =?Windows-1252?Q?zneuWmQsj/i3Ph/V0fxh8Ct6o1tegXpi+yJ5qbDY3mh3JzB7n5S9VrZM?= =?Windows-1252?Q?l+6KRVT6ciSxaMpkGOwuTfw105MI2m0VUqp4c2AM3+IsrnmHvLAbTVk8?= =?Windows-1252?Q?w3sZI3X9Atrx3bUh+Muqt3XHYFSIKJrvUWJoP75dHQ7R83gC/yvd+8U6?= =?Windows-1252?Q?siurTNf9bvRfYKKuEiAq248mquUDMN0W82ZGknYfGN0bXaoX+aaTM/31?= =?Windows-1252?Q?xhR7LCluVksXvsmyPP2psQB7/YgVAjEazZRJsC5YMMvhdAg8v7uehvvb?= =?Windows-1252?Q?ihghX0Rrq1b8CG7doIfobFGhManVI6/FGFbzbTqHR93Vs7/zGubrIiN1?= =?Windows-1252?Q?MMLrP2GQZUEE9jrGX6ZfGbN+AJu3W/Sl1w9iBquWShGuQE6HS55DOFRa?= =?Windows-1252?Q?QhF+QdkDCQMZ46/oBNNp6eHgF+ukPBeh5P/J9Shc01UWv85kUyIUbD4+?= =?Windows-1252?Q?uH+wdfQt3BnYj07mopRpIAaiepBPRXbauGQ9ZA9hR4LQIQ/VUo2gXSrb?= =?Windows-1252?Q?dKHSW2XLC0zeMOPVX7Dx273JO4e92wHdFwuFqbOLn6bBNKCmhWPRdcI8?= =?Windows-1252?Q?3jdkuoc2HWhlqP/6zETAyEJiUvemzomR2LhQcjMy69Ec/kXtyZnN7MBR?= =?Windows-1252?Q?Jpwoi6IsfcDIj3OWdX3Os8dcg97GuDh1T36P9a9b+AgPtliC90Aa7Yxk?= =?Windows-1252?Q?2PdEmnrRWoL6ZUUzyfwrQBztHZA5OUTHecHMPcOpSb4F+GuYXMcHg2Jg?= =?Windows-1252?Q?rg14ZJE3Neqxmn53/+rgrzfM5hX3KxyD9plD/vAnmrwgi0incQbCDzrq?= =?Windows-1252?Q?9/QlnkCPGsuKjVf7zUCJXZT31GDxO8hyGJu+OO9vHI/RdO0IDEMhWNLX?= =?Windows-1252?Q?lik=3D?= MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0945.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 1904b7b5-fb89-419c-56a6-08d9e278f950 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2022 16:12:25.5443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P190MB1132 X-Groupsio-MsgNum: 86178 Content-Language: en-US Content-Type: multipart/related; boundary="_004_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_"; type="multipart/alternative" --_004_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_ Content-Type: multipart/alternative; boundary="_000_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_" --_000_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pedro, what are you talking about? Please send disassemblies, map files, C samples= programs. Let=92s focusing on the most urgent intrinsic function needed for / % << an= d >> operators first. Quick note are really not helpful, but irritating. Regrads, Kilian From: Pedro Falcato Sent: Friday, January 28, 2022 05:00 PM To: edk2-devel-groups-io; kraxel@redhat.com Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl s= ubmodule to v3.0 Also, quick note: I've seen linking blowing up because the ABIs being used = in the bare metal code and in libgcc were different; this was in riscv64. I= know x86 doesn't do such checks but a few others do, including RISCV (they= tag object files with the ABI). This makes libgcc unusable in such archite= ctures. If we want to provide intrinsics, then possibly shipping our own compiler-r= t would be the only solid option. On Fri, 28 Jan 2022, 14:07 Gerd Hoffmann, > wrote: Hi, Oops, dropped the list by mistake, forwarding ... ----- Forwarded message from "kraxel@redhat.com" = > ----- Date: Fri, 28 Jan 2022 10:35:10 +0100 Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 From: "kraxel@redhat.com" > To: Kilian Kegel = > Message-ID: <20220128093510.atupc4ly6bvwinlk@sirius.home.kraxel.org> Content-Type: text/plain; charset=3Dutf-8 Hi, > On my 32Bit Ubuntu standard installation I ran > > 1. cc - Xlinker -Map=3Dstatic.map hello.c -static > 2. cc -Xlinker -Map=3Dshared.map hello.c > > The first .OBJ file mentioned in the .MAP file is in both cases: > /usr/lib/gcc/i686-linux-gnu/6/libgcc.a(_udivdi3.o) Yes, you are correct. gcc provides both shared and static intrinsics. There is a command line switch to pick which one you want (-static-libgcc, -shared-libgcc). > It seems to me that GNU holds the intrinsic functions in a separate libra= ry > that can be used without any change, and is always correct by definition. > 1. add libgcc.a as a search library, adjust the conf\tools_def.txt lik= e: > > DEBUG_GCCxx_IA32_DLINK_FLAGS =3D =85predefined parameter =85 /usr/lib/g= cc/i686-linux-gnu/6/libgcc.a gcc documentation suggests to use just '-lgcc' (should pick the correct library no matter what the compiler version and architecture is), so I tried this: -DEFINE GCC_DLINK2_FLAGS_COMMON =3D -Wl,--script=3D$(EDK_TOOLS_PATH)/Sc= ripts/GccBase.lds +DEFINE GCC_DLINK2_FLAGS_COMMON =3D -Wl,--script=3D$(EDK_TOOLS_PATH)/Sc= ripts/GccBase.lds -lgcc Build doesn't come very far. Looks like the gcc intrinsics are not free-standing but want call into libc: /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in f= unction `__absvdi2': (.text+0x18): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in f= unction `__absvsi2': (.text+0x32): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvdi2.o): in f= unction `__absvti2.cold': (.text.unlikely+0x2): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvsi3.o): in f= unction `__addvdi3': (.text+0xf): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvsi3.o): in f= unction `__addvsi3': (.text+0x2d): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvdi3.o):(.tex= t.unlikely+0x2): more undefined references to `abort' follow /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_eprintf.o): in f= unction `__eprintf': (.text+0x8): undefined reference to `stderr' /usr/bin/ld: (.text+0x1d): undefined reference to `fprintf' /usr/bin/ld: (.text+0x25): undefined reference to `fflush' /usr/bin/ld: (.text+0x2a): undefined reference to `abort' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(generic-morestack= .o): in function `__morestack_fail': (.text+0xbc): undefined reference to `writev' [ ... more errors snipped ... ] The generic-morestack.o issues should be solvable, that shouldn't be something which tianocore actually needs. Not sure why the linker tries to resolve symbols for object files which should not be needed in the first place. Possibly something else is fishy here, any hints are welcome. Something in the linker script maybe? But the math intrinsics apparently having error paths which print a message and abort doesn't look very promising to me. Also: When trying arm cross-builds I run into the ABI problem already mentioned elsewhere in this thread: /usr/bin/arm-linux-gnu-ld: error: /usr/lib/gcc/arm-linux-gnueabi/11/libgcc.= a(_muldi3.o) uses VFP register arguments, /home/kraxel/projects/edk2/Build/= ArmVirtQemu-ARM/DEBUG_GCC5/ARM/OvmfPkg/VirtioBlkDxe/VirtioBlk/DEBUG/VirtioB= lkDxe.dll does not Patches are here: https://github.com/kraxel/edk2/commits/intrinsics-playground > >* I have my doubts that compiler's builtin libraries are optimized for > > size, so I'd suspect we would see a noticeable size grow from that. > Please check the size of __udivdi3() and whether the tianocore reimplemen= tation is smaller or not I'll rather check the size of the final binaries, but I can only do that once the build works ... > The intrinsic library belongs to the compiler not to the build system. I'm open to explore that path, but apparently we have a number of road blocks along the way. Seems neither gcc nor xcode (see other reply) provide a usable free-standing intrinsic library ... take care, Gerd --_000_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Pedro,

 

what are you talking about? Please send disassemblie= s, map files, C samples programs.

Let=92s focusing on the most urgent intrinsic functi= on needed for / % << and >> operators first.

 

Quick note are really not helpful, but irritating.

 

Regrads,

Kilian

 

From: Pedro Falcato
Sent: Friday, January 28, 2022 05:00 PM
To: edk2-devel-groups-io= ; kraxel@redhat.com
Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update op= enssl submodule to v3.0

 

Also, quick note: I've seen linking blowing up becau= se the ABIs being used in the bare metal code and in libgcc were different;= this was in riscv64. I know x86 doesn't do such checks but a few others do= , including RISCV (they tag object files with the ABI). This makes libgcc unusable in such architectures.

 

If we want to provide intrinsics, then possibly ship= ping our own compiler-rt would be the only solid option.

 

On Fri, 28 Jan 2022, 14:07 Gerd Hoffmann, <kraxel@redhat.com> wrote:<= /p>

  Hi,

Oops, dropped the list by mistake, forwarding ...

----- Forwarded message from "kraxel@redhat.com" <kraxel@redhat.com> -----

Date: Fri, 28 Jan 2022 10:35:10 +0100
Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl  submodule to v3.0
From: "kraxel@r= edhat.com" <kraxel@redhat.com>
To: Kilian Kegel <kilian_kegel@outlook.com>
Message-ID: <20220128093510.atupc4ly6bvwinlk@sirius.hom= e.kraxel.org>
Content-Type: text/plain; charset=3Dutf-8

  Hi,

> On my 32Bit Ubuntu standard installation I ran
>
>   1.  cc - Xlinker -Map=3Dstatic.map hello.c -static >   2.  cc  -Xlinker -Map=3Dshared.map hello.c
>
> The first .OBJ file mentioned in the .MAP file is in both cases:
> /usr/lib/gcc/i686-linux-gnu/6/libgcc.a(_udivdi3.o)

Yes, you are correct.  gcc provides both shared and static intrinsics.=
There is a command line switch to pick which one you want
(-static-libgcc, -shared-libgcc).

> It seems to me that GNU holds the intrinsic functions in a separate li= brary
> that can be used without any change, and is always correct by definiti= on.

>   1.  add libgcc.a as a search library, adjust the conf= \tools_def.txt like:
>
> DEBUG_GCCxx_IA32_DLINK_FLAGS   =3D =85predefined parameter = =85 /usr/lib/gcc/i686-linux-gnu/6/libgcc.a

gcc documentation suggests to use just '-lgcc' (should pick the correct
library no matter what the compiler version and architecture is), so I
tried this:

-DEFINE GCC_DLINK2_FLAGS_COMMON     =3D -Wl,--script=3D$(EDK= _TOOLS_PATH)/Scripts/GccBase.lds
+DEFINE GCC_DLINK2_FLAGS_COMMON     =3D -Wl,--script=3D$(EDK= _TOOLS_PATH)/Scripts/GccBase.lds -lgcc

Build doesn't come very far.  Looks like the gcc intrinsics are not free-standing but want call into libc:

/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in f= unction `__absvdi2':
(.text+0x18): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in f= unction `__absvsi2':
(.text+0x32): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvdi2.o): in f= unction `__absvti2.cold':
(.text.unlikely+0x2): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvsi3.o): in f= unction `__addvdi3':
(.text+0xf): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvsi3.o): in f= unction `__addvsi3':
(.text+0x2d): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvdi3.o):(.tex= t.unlikely+0x2): more undefined references to `abort' follow
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_eprintf.o): in f= unction `__eprintf':
(.text+0x8): undefined reference to `stderr'
/usr/bin/ld: (.text+0x1d): undefined reference to `fprintf'
/usr/bin/ld: (.text+0x25): undefined reference to `fflush'
/usr/bin/ld: (.text+0x2a): undefined reference to `abort'
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(generic-morestack= .o): in function `__morestack_fail':
(.text+0xbc): undefined reference to `writev'
[ ... more errors snipped ... ]

The generic-morestack.o issues should be solvable, that shouldn't be
something which tianocore actually needs.  Not sure why the linker tri= es
to resolve symbols for object files which should not be needed in the
first place.  Possibly something else is fishy here, any hints are
welcome.  Something in the linker script maybe?

But the math intrinsics apparently having error paths which print a
message and abort doesn't look very promising to me.

Also: When trying arm cross-builds I run into the ABI problem already
mentioned elsewhere in this thread:

/usr/bin/arm-linux-gnu-ld: error: /usr/lib/gcc/arm-linux-gnueabi/11/libgcc.= a(_muldi3.o) uses VFP register arguments, /home/kraxel/projects/edk2/Build/= ArmVirtQemu-ARM/DEBUG_GCC5/ARM/OvmfPkg/VirtioBlkDxe/VirtioBlk/DEBUG/VirtioB= lkDxe.dll does not

Patches are here:
  https://github.com/kraxel/edk2/commits/intrinsics-playground

> >* I have my doubts that compiler's builtin libraries are optimized= for
> >   size, so I'd suspect we would see a noticeable size g= row from that.
> Please check the size of __udivdi3() and whether the tianocore reimple= mentation is smaller or not

I'll rather check the size of the final binaries, but I can only do that once the build works ...

> The intrinsic library belongs to the compiler not to the build system.=

I'm open to explore that path, but apparently we have a number of road
blocks along the way.  Seems neither gcc nor xcode (see other reply) provide a usable free-standing intrinsic library ...

take care,
  Gerd





 

--_000_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_-- --_004_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_ Content-Type: image/png; name="5596062C75D4463FA81E7F7EAF4C73EE.png" Content-Description: 5596062C75D4463FA81E7F7EAF4C73EE.png Content-Disposition: inline; filename="5596062C75D4463FA81E7F7EAF4C73EE.png"; size=132; creation-date="Fri, 28 Jan 2022 16:12:25 GMT"; modification-date="Fri, 28 Jan 2022 16:12:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAsQAAAABCAYAAADZ77itAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAZSURBVEhL7cEBAQAAAIIg/69uSEAAAPCrBgsR AAHZdg1RAAAAAElFTkSuQmCC --_004_AM8P190MB09459A73B799DA9E3B65C25FEB229AM8P190MB0945EURP_--