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, <kraxel@redhat.com> wrote:

>   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@redhat.com" <kraxel@redhat.com>
> To: Kilian Kegel <kilian_kegel@outlook.com>
> Message-ID: <20220128093510.atupc4ly6bvwinlk@sirius.home.kraxel.org>
> Content-Type: text/plain; charset=utf-8
>
>   Hi,
>
> > On my 32Bit Ubuntu standard installation I ran
> >
> >   1.  cc - Xlinker -Map=static.map hello.c -static
> >   2.  cc  -Xlinker -Map=shared.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 definition.
>
> >   1.  add libgcc.a as a search library, adjust the conf\tools_def.txt
> like:
> >
> > DEBUG_GCCxx_IA32_DLINK_FLAGS   = …predefined parameter …
> /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     =
> -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> +DEFINE GCC_DLINK2_FLAGS_COMMON     =
> -Wl,--script=$(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/VirtioBlkDxe/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
>
>
>
> 
>
>
>