From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web12.5106.1661073215873873820 for ; Sun, 21 Aug 2022 02:13:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iXsx1Hm8; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id B9F40B80BE6 for ; Sun, 21 Aug 2022 09:13:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2CCBC43142 for ; Sun, 21 Aug 2022 09:13:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661073211; bh=SQyY6d8iONcmZOvySBtIgHaXAIB9tQRk7eh9meUm7io=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iXsx1Hm8wM6Cm5Or8SDgvM9xiDcffGt1IMXsCiRtluzus7jomoO6tvMzWLwhSrq6u cSiae+OVxz2+drjOWkZHwqJHBsAas51MaIhVkx6Zqm26f1XeO82haochsPxlIdNZSJ T3kAl1cdaz4gM5ysm7C52fCPZFwfux8Ylz+/cKm+KDFTx6o9mf/dchtiN4gDXA/rcg lhSerQMuQmPllX/wedPtftMH/v+W3PmNMcbMmnJkc5bHHMoiecMMHXHKmZqDSj/Dev 6ZeRJ7xfJjoIUh9GSYPuUr0LHxbo2aEOplFhT6lm9/0hEH2pYNyIe7sGzHqbNCXOtk S1hzV7Vwd6V0w== Received: by mail-wr1-f46.google.com with SMTP id n4so9804307wrp.10 for ; Sun, 21 Aug 2022 02:13:31 -0700 (PDT) X-Gm-Message-State: ACgBeo0+DwQYj9Nvi/j7a0vOR+zml6M3kH7tSC7ImrEdmxcxRs7q/VgE sLsRgWJbNtdQDcKdedRJIPegvyaLQG7mdMCR4zc= X-Google-Smtp-Source: AA6agR5fJdvjFxZ0Nl//AXmYTA8dbewjjroQJ1hrvNbjzSnFJ/0p0nxog1JvnTc8iR44FH0oKBYa8BKcc6IyS714zmA= X-Received: by 2002:adf:ebd2:0:b0:222:cd3f:cf9 with SMTP id v18-20020adfebd2000000b00222cd3f0cf9mr8233616wrn.598.1661073209916; Sun, 21 Aug 2022 02:13:29 -0700 (PDT) MIME-Version: 1.0 References: <5401edf1-a6a5-9193-2be5-cff2cf64081f@bsdio.com> In-Reply-To: <5401edf1-a6a5-9193-2be5-cff2cf64081f@bsdio.com> From: "Ard Biesheuvel" Date: Sun, 21 Aug 2022 11:13:18 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_) To: Rebecca Cran Cc: devel@edk2.groups.io, "Kinney, Michael D" , Leif Lindholm , Ard Biesheuvel , Andy Hayes , Pedro Falcato , =?UTF-8?Q?Marvin_H=C3=A4user?= , Masami Hiramatsu Content-Type: text/plain; charset="UTF-8" On Sat, 20 Aug 2022 at 01:35, Rebecca Cran wrote: > > I have an armplatbld.sh script that goes through and tries to build as many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible. > > I'm think this used to work for these, but I'm getting some errors now. > > I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d. > > > Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard and __stack_chk_fail) > > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with undefined references to __stack_chk_guard and __stack_chk_fail) > Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type. For example, absolute and undefined symbols are not supported.) > > Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references to __stack_chk_guard and __stack_chk_fail) > Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type. For example, absolute and undefined symbols are not supported.) > Hello Rebecca, Which compiler and linker are you using? The *Mm.dsc targets are a bit tricky to build, as they self-relocate while running in a secure partition, which has restrictions in terms of memory permissions. I don't remember the exact details, but it is likely we never bothered to test Clang, and Visual Studio definitely doesn't work. As for the stack protector - as you already identified, this is a matter of adding the appropriate NULL library class resolution. The heuristics regarding which functions need a stack cookie and which don't is not set in stone, nor is the default strength, which can vary per compiler build between distros.