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.71754.1679577261697336943 for ; Thu, 23 Mar 2023 06:14:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ImrHWT4T; 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 CB78E626BB for ; Thu, 23 Mar 2023 13:14:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8568DC4331E for ; Thu, 23 Mar 2023 13:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679577260; bh=rdO41E3MxkfxtZfwaU8lWIwpick10cpSnYdD7tV3FAk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ImrHWT4TpUuDatdH+8bBzHPqWI/ZUIpXDDMgh9jbHpU2L5YkPbVR/OyXzrHPx7xzw 3GpHsGmFPlf2SrT03dXELnhmWobG3QRLJ0/s3q4aFB4+/gOuc1U4oaxhDk07DX2oJR KxeDXuxtsCy4KWLSstlr/z9sqZAkkhAtdBJURPn/ccRBA0yXgg/hmgzBuwSh/WTUVt gOkZ8i9FtDH9C3mcfDTDwOhX1FndjsXy6mLwYb77aTIzpE1jfIpfGCWSKpmQNELY9h qlldgQSGjkkFyK8r5og4pfMR6Xko2A/fI/f/Aix18AkZ9fglK1dCQMowue9BU90tmy cLclPQBOubfig== Received: by mail-lf1-f53.google.com with SMTP id br6so27658202lfb.11 for ; Thu, 23 Mar 2023 06:14:20 -0700 (PDT) X-Gm-Message-State: AAQBX9cEp7UpKVEMOevwZogFSxze7akA6pGvak3ARqCfmORvnjJcShVI gj850Q70AA5/+e7vrFPY5j4FKX3D+tRId8u+afA= X-Google-Smtp-Source: AK7set9jchkjRpPV/X1IsKgOQYPGu18P7GiAwRLjD5jK0g8uqV8ICHMCxzK+PLdfNFAOytPFPHUGvLtGHw++qCf0gbo= X-Received: by 2002:ac2:53a9:0:b0:4ea:12f7:a725 with SMTP id j9-20020ac253a9000000b004ea12f7a725mr3024588lfh.4.1679577258500; Thu, 23 Mar 2023 06:14:18 -0700 (PDT) MIME-Version: 1.0 References: <20230322013040.3322865-1-rebecca@bsdio.com> <20230322013040.3322865-4-rebecca@bsdio.com> <5f85abe6-4a08-0f70-9efc-d671770c1201@bsdio.com> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 23 Mar 2023 14:14:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/9] BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and CLANG38 To: Rebecca Cran Cc: devel@edk2.groups.io, Michael D Kinney , Liming Gao , Zhiguang Liu , Bob Feng , Yuwei Chen , Andrew Fish , Leif Lindholm , Ard Biesheuvel , Jordan Justen , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" On Thu, 23 Mar 2023 at 10:04, Ard Biesheuvel wrote: > > On Thu, 23 Mar 2023 at 02:30, Rebecca Cran wrote: > > > > On 3/22/23 5:49 AM, Ard Biesheuvel wrote: > > > > > > > > The reason I added CLANG3x support for ARM in the past is to ensure > > > compatibility with the ARM proprietary, Clang based toolchain. At the > > > time, we went with GNU ld, but I would actually prefer if we could > > > make this work with LLD as well. > > > > Just to confirm, I'll keep lld for X64 and IA32, but I won't add > > -fuse-ld=lld for ARM or AARCH64 since none of the toolchain definitions > > currently do so. > > > > > > The problem with trying to use lld for aarch64 is the following error: > > > > > > GenFw: ERROR 3000: Invalid > > WriteSections64(): > > /home/bcran/uefi/edk2/Build/ArmVirtQemu-AARCH64/RELEASE_CLANGDWARF/AARCH64/ArmVirtPkg/MemoryInitPei/MemoryInitPeim/DEBUG/MemoryInit.dll > > due to its size (> 1 MB), this module requires 4 KB section alignment. > > > > That seems to be a false positive error in GenFw. > > It looks like LLD turns > > ADRP > ADD > > into > > NOP > ADR > > if the target is within -/+ 1 MiB but it doesn't update the > relocations, so GenFw goes off into the weeds. I.e.. > > 304: d503201f nop > 304: R_AARCH64_ADR_PREL_PG_HI21 .data > 308: 100015c1 adr x1, 5c0 > 308: R_AARCH64_ADD_ABS_LO12_NC .data > > This is just another indication that using --emit-relocs is a bad > idea, and we should really be building PIE executables and converting > those based on the dynamic relocation instead. > > Adding -Wl,--no-relax to the DLINK flags should help with this, > although I notice that there are other LLD related issues, in the ID > map code I added to ArmVirtQemu a while ago, so ArmVirtQemu.dsc still > does not build. So I played around with this a bit more, also on ARM, and it seems to me that simply disabling PIE linking is the best approach here - the PE/COFF conversion essentially turns it into a relocatable binary already, and so PIE linking does not actually add anything useful here, and on ARM, the resulting ELF binary triggers an assert in GenFw So adding -fuse-ld=lld -Wl,--no-relax,--no-pie to both CLANG38_AARCH64_DLINK_FLAGS and CLANG38_ARM_DLINK_FLAGS works for me locally, i.e., builds complete without errors and can boot successfully. We will also be able to drop the GccLto plugin pass through libraries, which is rather nice as well.