From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by mx.groups.io with SMTP id smtpd.web08.14.1643385254221100098 for ; Fri, 28 Jan 2022 07:54:14 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=E/AhtWN8; spf=pass (domain: gmail.com, ip: 209.85.217.50, mailfrom: pedro.falcato@gmail.com) Received: by mail-vs1-f50.google.com with SMTP id x13so3530665vsl.10 for ; Fri, 28 Jan 2022 07:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yW0es6ziNB601m5aGGHCGI4Z4ynpRR/2zxRpynFujmY=; b=E/AhtWN8kbJ8YVdNjVqB/g4ttsy/MfFjGlDaSiLHYisD6Sx9aqNLHhvH7nJrVo4jAX JBBm/TnugXR+RFcMOvPbEfgT/IKkZp0IuKKnCoixVPVAn52JNFFAsg0IAFu/ZBfrAR5h LkPterZjq96+T727vySdmonjXYUVo3PZLzNdeffZzYdeMu8reG7AYYEXXaD1yOWL5Cft V72uEH1OsEy0eqgasXP5tQmUPdT8pAB1mxOY+sveFR6F53gV5l0uBwsbjXpqMIYMDNOa S2gx05zHFUv+o4M7urpUyq4O4CwsWUiATghu8EAT7/UzCk7/CiNmyQ+eFbnSogoE0mYv WJ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yW0es6ziNB601m5aGGHCGI4Z4ynpRR/2zxRpynFujmY=; b=qqWakg7Um74lTNAlnk6NhzxedaxbBPasimQ3AV0Pmc92aAcdaddU2BBjXq8VmbSqM8 gzUHgAYX/gEEspvr0jt6bRiYIKbOjIlGxvHGvNlMBa1wu69yE86k8fQ4qUCC+0+A9zcF L1KmR96H58p3ZvPIq0/KSwRZ+WgcvbmANlmrMs5KBxC6onGutB25Pco/xFcRycugQKAK 8q1sgZn8+CdfJSCh5hgtcKCiEm9zlexV8LatQMydV8hKCFTXfdJJld5079ZbRq+F7mCM Jg0t6rZGSw9toHqORnM1ojZjH1uJxEcGxBRIE3Cz90lFBRd1A+PImKaUtu7VQ8RMilEM C8cg== X-Gm-Message-State: AOAM533MD6gNAFpmixiBBL8C+cXIbFf9RSrnWp9YxPZl06ILd7XXJ8F+ PRGLW2BXC75do4XUCSQteuDP1F6NGmohnEKQBTeBEnJuxeY= X-Google-Smtp-Source: ABdhPJzwZhs4itBtBNkFr1zqWt/gx8ry/kBEmNHrTCpeelJA8AeLu22Mx2JbDrAsHNu6O3CwNVbRfzgGC/+DydfViUM= X-Received: by 2002:a05:6102:153:: with SMTP id a19mr3948456vsr.75.1643385253103; Fri, 28 Jan 2022 07:54:13 -0800 (PST) MIME-Version: 1.0 References: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org> In-Reply-To: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org> From: "Pedro Falcato" Date: Fri, 28 Jan 2022 15:54:00 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 To: edk2-devel-groups-io , kraxel@redhat.com Content-Type: multipart/alternative; boundary="0000000000003d8dbb05d6a6727a" --0000000000003d8dbb05d6a6727a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gerd, As I mentioned earlier, abort() is one of 5 functions GCC expects in freestanding mode (plus memset, mempy and two others). Is there any floating point enabled somewhere? I really don't remember having seen those undefined references to fprintf, ever. I thought that was only used in floating point stuff. A dummy implementation should suffice though. Thanks, Pedro 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 > library > > that can be used without any change, and is always correct by definitio= n. > > > 1. add libgcc.a as a search library, adjust the conf\tools_def.txt > like: > > > > DEBUG_GCCxx_IA32_DLINK_FLAGS =3D =E2=80=A6predefined parameter =E2=80= =A6 > /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 > function `__absvdi2': > (.text+0x18): undefined reference to `abort' > /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvsi2.o): in > function `__absvsi2': > (.text+0x32): undefined reference to `abort' > /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_absvdi2.o): in > function `__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 > function `__addvdi3': > (.text+0xf): undefined reference to `abort' > /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvsi3.o): in > function `__addvsi3': > (.text+0x2d): undefined reference to `abort' > /usr/bin/ld: > /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_addvdi3.o):(.text.unlikely+= 0x2): > more undefined references to `abort' follow > /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/11/libgcc.a(_eprintf.o): in > function `__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/V= irtioBlkDxe/VirtioBlk/DEBUG/VirtioBlkDxe.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 > reimplementation 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 > > > >=20 > > > --0000000000003d8dbb05d6a6727a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gerd,

As I m= entioned=C2=A0earlier, abort() is one of 5 functions GCC expects in freesta= nding mode (plus memset, mempy and two others).

=
Is there any floating point enabled somewhere? I re= ally don't remember having seen those undefined references to fprintf, = ever. I thought that was only used in floating point stuff. A dummy impleme= ntation should suffice though.

Thanks,
Pedro=C2=A0

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

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

----- Forwarded message from "kraxel@redhat.com" &l= t;kraxel@redhat.com> -----

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

=C2=A0 Hi,

> On my 32Bit Ubuntu standard installation I ran
>
>=C2=A0 =C2=A01.=C2=A0 cc - Xlinker -Map=3Dstatic.map hello.c -static >=C2=A0 =C2=A02.=C2=A0 cc=C2=A0 -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.=C2=A0 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.

>=C2=A0 =C2=A01.=C2=A0 add libgcc.a as a search library, adjust the conf= \tools_def.txt like:
>
> DEBUG_GCCxx_IA32_DLINK_FLAGS=C2=A0 =C2=A0=3D =E2=80=A6predefined param= eter =E2=80=A6 /usr/lib/gcc/i686-linux-gnu/6/libgcc.a

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

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

Build doesn't come very far.=C2=A0 Looks like the gcc intrinsics are no= t
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.=C2=A0 Not sure why the linker tri= es
to resolve symbols for object files which should not be needed in the
first place.=C2=A0 Possibly something else is fishy here, any hints are
welcome.=C2=A0 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:
=C2=A0 https://git= hub.com/kraxel/edk2/commits/intrinsics-playground

> >* I have my doubts that compiler's builtin libraries are optim= ized for
> >=C2=A0 =C2=A0size, so I'd suspect we would see a noticeable si= ze grow 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 tha= t
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<= br> blocks along the way.=C2=A0 Seems neither gcc nor xcode (see other reply) provide a usable free-standing intrinsic library ...

take care,
=C2=A0 Gerd






--0000000000003d8dbb05d6a6727a--