From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.7442.1643378856655174177 for ; Fri, 28 Jan 2022 06:07:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AtRRNpuH; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643378855; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8ywMY/rKhO9Ra3T50GXjahe6tNFPg5k48++Ftdbz4BY=; b=AtRRNpuHERIdQMk63JnL6IGgZgYDkMOGO7fy//Wekhb9HMpVyTTTICWzlRkvSguLiBNSaZ kIG6uPk0nNfvTMtHb3odfhyPlvrSNKaeQYQEWItCC2iPujNReqPQ57mCEDz0nlowL1OeIH wCUYGMRCqrL9p8MYQehnSI+bK8Ob8Kc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-118-Nxjp1RnyMJ65M7hsx4BjQg-1; Fri, 28 Jan 2022 09:07:32 -0500 X-MC-Unique: Nxjp1RnyMJ65M7hsx4BjQg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5019464143 for ; Fri, 28 Jan 2022 14:07:31 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D49A784635 for ; Fri, 28 Jan 2022 14:07:30 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0115D180060D; Fri, 28 Jan 2022 15:07:23 +0100 (CET) Date: Fri, 28 Jan 2022 15:07:23 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Message-ID: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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=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