From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.6690.1681819198013748168 for ; Tue, 18 Apr 2023 04:59:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cbDKUnjv; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D48162CDB for ; Tue, 18 Apr 2023 11:59:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5983AC433A0 for ; Tue, 18 Apr 2023 11:59:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681819196; bh=eW+jsDbRJzhpqEyRrlM9fqIdeYxURUSrCXBjTti+2u8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cbDKUnjvKKYrGgGMFJ1LnybHVjLT05B0Omoi4PtS/GGBaaULoc+n69ZkE4m6FMM17 OOe/DGHfgegVStt2j8EAfPDRqvCD7fKtJAxutDRXDTd2mTFJanN4WqrhZGZMzWFW3D +/rVtmc8tQvRLQaQqiXqVX9pm6ke4G0tsMH3Z8SL/hhf5IcL7VFFZkXiRt2o/68qtC 2CQZAAERjFmYOctWWJxP74z4/We7Rmkv6CaBb2Eo0mubFMO9WhiGXEo4npEvqY4p7K 1lcibpC+DNTLYc12j7BBerAv61eXXbhU0IKKMbzYseUyO2W8f2a/B0zdO+7WViD+ww S24OQpulMSXOQ== Received: by mail-lj1-f169.google.com with SMTP id k15so12058678ljq.4 for ; Tue, 18 Apr 2023 04:59:56 -0700 (PDT) X-Gm-Message-State: AAQBX9dBsCvNFmBgUijCgpHZQNzRlcT5n57V7/f6HQC6XeCR7PFo7yk/ wxDcJWLbaVWnT1xB+a20Gjs4mggYBivfKanViIw= X-Google-Smtp-Source: AKy350aoRgKiVEm1urIKpshdqampZNi2fJtSPUHevPpj9Zao/N04XhoApiAT06vU+qHXSWABE2dsUZ+lbfobtzVi68A= X-Received: by 2002:a2e:9c96:0:b0:2a8:bc05:1d7a with SMTP id x22-20020a2e9c96000000b002a8bc051d7amr615701lji.30.1681819194348; Tue, 18 Apr 2023 04:59:54 -0700 (PDT) MIME-Version: 1.0 References: <20230414080250.1357004-2-kraxel@redhat.com> <18EC1A6E-8B81-4564-83A5-DA8EC2BA54ED@posteo.de> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 18 Apr 2023 13:59:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define To: Gerd Hoffmann Cc: devel@edk2.groups.io, =?UTF-8?Q?Marvin_H=C3=A4user?= , Pawel Polawski , Dongyan Qian , Sunil V L , Baoqi Zhang , Chao Li , Rebecca Cran , Ard Biesheuvel , Zhiguang Liu , Liming Gao , Yuwei Chen , Leif Lindholm , Michael D Kinney , Daniel Schaefer , Bob Feng , Oliver Steffen Content-Type: text/plain; charset="UTF-8" On Tue, 18 Apr 2023 at 13:52, Gerd Hoffmann wrote: > > Hi, > > > > Underlying problem is that x64 ProcessorBind.h sets visibility to > > > hidden (anyone knows why?). > > > > Yes. Toolchains tend to assume that you are generating code for a > > shared library once you enabled -fpic, and this results in lots of > > pointless indirections via the GOT. (This has to do with the > > copy-on-write footprint of shared library pages, as a GOT tends to > > gather all relocated quantities in a small region of memory. It is > > also related to ELF symbol preemption, which is another thing we don't > > give a ^$& about). > > > > *However*, recent linkers do a better job getting rid of these GOT > > references at link time, once you pass the --relax option. On X64 in > > particular, there are special, relaxable GOTPCREL relocations now that > > will not result in to symbol references via the GOT if the linker > > notices that the symbol in question is never preempted and not > > provided externally. > > > > So it is worth an experiment whether we still need this to begin with. > > Seems to work fine on fedora 37, even without adding --relax, maybe this > is enabled by default (there is a --no-relax switch after all). I'll go > try older distros / compilers / binutils too. > > What would be the failure mode? Errors on ELF -> PE conversion because > a GOT is present? Or will things break at runtime? > The problem here is that we rely on --emit-relocs to get at the relocations in the binary, in order to convert the absolute ones into PE/COFF relocations. However, --emit-relocs did not use to cover the GOT, as those are added at the end by the linker and not by the compiler. So if the GOT is non-empty, the resulting PE executable will be corrupt. Of course, the answer here is to dump GenFw altogether for ELF to PE conversion, and implement something that consumes the dynamic relocations generated when linking in PIE mode. > > > Seems to be fine for freestanding binaries, > > > but when linking host tools against shared libraries things break. For > > > some reason on ubuntu only, fedora works fine (both gcc and clang). > > > > > > Automatically detecting freestanding vs. hosted would be even better, > > > anyone knows whenever there is a define which can be used for this? At > > > least the gcc man page doesn't mention any ... > > > > ard@gambale:~/linux-build-x86$ gcc -dM -E -o - -xc - <<< ""|grep HOSTED > > #define __STDC_HOSTED__ 1 > > ard@gambale:~/linux-build-x86$ gcc -ffreestanding -dM -E -o - -xc - > > <<< ""|grep HOSTED > > #define __STDC_HOSTED__ 0 > > Nice. So we have a plan b in case just dropping it doesn't work out. > > take care, > Gerd >