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.web11.11994.1681484264116422811 for ; Fri, 14 Apr 2023 07:57:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZmGYi98p; 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 8B7DC6465D for ; Fri, 14 Apr 2023 14:57:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1A4BC433D2 for ; Fri, 14 Apr 2023 14:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681484263; bh=oH2HDP2fVP8VpinOZHjVbR0eRLifVbTZph7JFlG8x8E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZmGYi98pIy3zfwZhdCjnBUhVEesncLYMWDByUKlW8gq/5PqPlVFV6Z5zz8TF58T3P rA4+BZycmacxhzaQ17JdaXz+XPBBHeMLVDoOSPypfOIDYxvU9BCzlgkS8aGs9/vN5F BwBCASHK324SE1GOa+mOW24S3ai+2uu5nvDUGOFNdMBxlV+DaUVDgvcIhJQpKRRRee x2toJRUTQXTXIIzXULGzMmmWisxoRl+c4jNtujaO8JdoqULWuvxkuje2VLy7UZzBDQ 55GJRxpjYOfoXpd5e9ICw3IMIIu/ENLA/rBiua8TXq7peYNUAhd+bbY56AbtWE+Bt2 AmeORYrgVof6g== Received: by mail-lf1-f52.google.com with SMTP id m4so23543021lfj.13 for ; Fri, 14 Apr 2023 07:57:42 -0700 (PDT) X-Gm-Message-State: AAQBX9d5JcFeOw/aec5tVZLJWt7q1ttKU7fYY1aCGa/oxSJor5lNA+VZ n36fEgUfDFVktSrKPMr6waBjPmiiazW5kLk6qQs= X-Google-Smtp-Source: AKy350ZxS9N3yP/xLxsEJf6PXmuuABTp8P2ZR22fIrLvLsPIEB3tHf2dbaaO/h/RHkOZ6Zwp1JkOGJfeBAuYqvd7n+I= X-Received: by 2002:ac2:5309:0:b0:4ec:9e40:e451 with SMTP id c9-20020ac25309000000b004ec9e40e451mr1976070lfh.9.1681484261028; Fri, 14 Apr 2023 07:57:41 -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: Fri, 14 Apr 2023 16:57:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define To: devel@edk2.groups.io, kraxel@redhat.com Cc: =?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" Content-Transfer-Encoding: quoted-printable On Fri, 14 Apr 2023 at 16:37, Gerd Hoffmann wrote: > > On Fri, Apr 14, 2023 at 12:29:21PM +0000, Marvin H=C3=A4user wrote: > > Hi Gerd, > > > > Thanks for your effort! > > > > Sorry, but I *really* dislike this =E2=80=9CBASETOOLS=E2=80=9D notion. = There might be > > external tools that also want to use the header (like we do with AUDK) > > and also edk2 supports host-based unit tests. Imo the macro name > > should be generic, like =E2=80=9CHOST_OS=E2=80=9D or =E2=80=9CUSERLAND= =E2=80=9D or something (I=E2=80=99m bad > > with names :) ). > > I'm certainly open to better naming ideas. > > 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 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