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.21164.1684760158491841568 for ; Mon, 22 May 2023 05:55:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lVHjS+xi; 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 BD26A61FFF for ; Mon, 22 May 2023 12:55:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1A40C433A8 for ; Mon, 22 May 2023 12:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684760156; bh=xcyuDwhaYcX6w2kTqGyiSpM6rh/duxyURRXZtkvhRl4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lVHjS+ximm/QlgB4TFoLSNlbxGZeiHMicLOgnlSze9hgIWIj0ygKwDQCx/eDgUJPX /Y6WT0jiLYLIfSnVCqqSVIqo/NO5WW+5S1Ap0+xvdyOnjeT4rxQyPNZdFdjN2qBZtA NdKxcRY6a5llYxTWHxrdQwRAqxRkzIZ5jTq0zXiw1CKoBoT++gjY3/oZHuFHwfSSpy E7CgfSiiCPBwXnQLmIYzWKyfliJPal2H7ASj/CpHidXod52B5XClCgrKD4ryCn28yX +IGrBw6xFrDIaufTWlGZ50Bzpjd+XlXH/gSqRd2WofpYJVdqleUHsETVFvlG6BvDF6 EOuiWFqc143cg== Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-4f3bb395e69so2041674e87.2 for ; Mon, 22 May 2023 05:55:56 -0700 (PDT) X-Gm-Message-State: AC+VfDwN3OycwyusH0yJ2hYnzaKTeyBtBeQAxWa6G1XzPdKHFBzRcHNP RxWQKxvu67gwivF+yKCrdCLNanNLZk/K0Or8Lrs= X-Google-Smtp-Source: ACHHUZ4AJL62H3KjYlNDlMUdYtkAXrhjGg2FotD5HKxGo/EcqkFDpskn/bQPKEAKZhLSRkv9JyZ6vXFowWQbQOrCMvc= X-Received: by 2002:a19:f611:0:b0:4f3:a7d3:28e0 with SMTP id x17-20020a19f611000000b004f3a7d328e0mr3445588lfe.28.1684760154633; Mon, 22 May 2023 05:55: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: Mon, 22 May 2023 14:55: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 Mon, 22 May 2023 at 14:28, Gerd Hoffmann wrote: > > Hi, > > So, after a way to long time gap, I finally found the time to look at > this again. This time tried both gcc and clang. > > Just dropping the visibility hidden #pragma works fine for gcc. It also > works with clang for DEBUG and RELEASE builds, but not for NOOPT builds. > So what failures are you seeing in this case? I assume this is using LLD. So the problem with LLD is that it does not update the static relocations it emits into the executables, so even if the linker relaxes any GOT based references, the relocation entry still claims that a GOT based reference exists. It should be possible in principle to detect this casein GenFw, but this would involve decoding the instruction to decide whether it uses a memory operand or not, and this doesn't seem worth the effort to me. Recent clang does have a '-fdirect-access-external-data' switch which should suppress these references, maybe in combination with -fvisibility=hidden? (The latter is usually insufficient by itself)