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.4726.1680865335861310154 for ; Fri, 07 Apr 2023 04:02:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BiLP/Lhg; 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 670356453D for ; Fri, 7 Apr 2023 11:02:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE6ABC4339B for ; Fri, 7 Apr 2023 11:02:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680865334; bh=w28tsUJrI+b09bET16jOD0tamuHX2kKOa8CTydbwpVg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BiLP/LhgYf09Wlj6b4R07rm38JW/zOPqJzhZRdfBol48oecEpU+2iIYXPjAnuHhvO Q4PzEOxAj2WmIWxtBvoVQlOoCvTX6bwJUJpnyGgtVFKp5cAArDVH4JnfhF4qzPwSQ8 BHmRsgF9S2ESLl3BpfH1RyLlkL3hFTwL9lkyzzHJP7LLm8hnRkaBNmKV+aBXn9VGTS 4SKqUxXOdTgt77r9aEVjzn7/cmoskuJ+ysg2etxZBU8nUNwN6VqiHeTPQQvz7CmnhQ ccNsbQYuVmUPwWsdIbumBl+FmAVdxAXhhuOhqIQhS6DnBfIZFkcCPTytyvhWYMZEkQ WpjOh8qxkxqaw== Received: by mail-lj1-f182.google.com with SMTP id s20so22924283ljp.7 for ; Fri, 07 Apr 2023 04:02:14 -0700 (PDT) X-Gm-Message-State: AAQBX9cmLeb9Uc5rEYgJW6qsr095cybXQ/TxboqjwmsA8sdPcoovcjbj sv1ZEu4lrl7Ylg6aaxpx2tA6hb45g9ozcs4FaFc= X-Google-Smtp-Source: AKy350ZMjiVCMC+vtKWSQvs1EaMxd0iE7H1XHBeylr3a+w1FlPYA5sEpQkY15ZEn0v57yuwwuAWtEHotfgnqd7wvnbw= X-Received: by 2002:a2e:a307:0:b0:2a5:f850:c356 with SMTP id l7-20020a2ea307000000b002a5f850c356mr471916lje.2.1680865332838; Fri, 07 Apr 2023 04:02:12 -0700 (PDT) MIME-Version: 1.0 References: <6DC21A1C-4321-499F-ACCD-D5C81D20DB11@posteo.de> In-Reply-To: <6DC21A1C-4321-499F-ACCD-D5C81D20DB11@posteo.de> From: "Ard Biesheuvel" Date: Fri, 7 Apr 2023 13:02:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] Role of DLINK2_FLAGS and link-time option consistency To: devel@edk2.groups.io, mhaeuser@posteo.de Cc: rebecca@bsdio.com, Liming Gao , Bob Feng , "Chen, Christine" , "Rudolph, Patrick" , Lean Sheng Tan , Pedro Falcato , Vitaly Cheptsov , Leif Lindholm , Steven Shi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 7 Apr 2023 at 12:14, Marvin H=C3=A4user wrote: > > Good day everyone, > > I've been asked to check the following patch: https://edk2.groups.io/g/de= vel/message/102168 > > One thing I noticed was that -no-pie is added to DLINK2_FLAGS, not DLINK_= FLAGS. For MSVC toolchains, DLINK2_FLAGS is used for a separate linker step= [1] introduced by [2], which makes sense to me. For GCC* and CLANG* toolch= ains, however, I haven't really been able to understand its purpose. Genera= lly, DLINK_FLAGS and DLINK2_FLAGS are used as part of the same command in t= he same fashion, e.g., [3]. The main difference I've been able to spot is t= hat the linker step for 16-bit ASM files omits DLINK2_FLAGS, but passes DLI= NK_FLAGS [4]. As MSVC uses a completely different linker flags macro for th= ese files and XCODE* toolchains use the static linker, it appears to be the= semantics of DLINK2_FLAGS are different between toolchains. That's my conf= usion for the consumer side, I don't understand the exact purpose, or why 1= 6-bit ASM in particular is special here. DLINK2_FLAGS unfortunately seems t= o date back to the "Sync BaseTools" SVN commits, so I didn't find much with= blame. > > For the producer side, I noticed --pie is passed for DLINK_FLAGS [5]. On = the other hand, the IA32 GCC definitions override this with -no-pie, but in= DLINK2_FLAGS (which the patch in question replicates). It's my understand = that this means the linker step for 16-bit ASM files will be the only linke= r step in a IA32 build process to use --pie, while all other steps will hav= e the -no-pie override. For the current codebase, there probably isn't much= of a difference. However, for a well-defined build behaviour, don't we nee= d to pass mostly the same linker flags (at the very least PIE-related flags= ) to all steps in the process? Is there a particular reason for how things = work the way they do right now? > > I've also tried to look at which kinds of flags are generally passed as D= LINK_FLAGS vs DLINK2_FLAGS. For some reason, the linker script and related = symbol definitions generally seem to be passed via DLINK2_FLAGS [8] as per = [9]. I could imagine a possible rationale could be selective replacement, w= here a platform can discard-and-reassign DLINK2 to pass its own linker scri= pt? I didn't find any evidence for this though. With Pedro, I discussed var= ious other possibilities for what could be the rationale for DLINK2_FLAGS, = but pretty much failed. One was, that one of them is meant to be passed to = the linker directly, while the other was supposed to be passed to the compi= ler (CC may be DLINK, or they may be different). However, there is a very i= nconsistent usage of "-Wl" between the two and LD does not support -Wl. > > Another (rather unrelated) oddity we noticed is that CLANGDWARF passes di= fferent optimization levels to CC and DLINK2 [8], which I'm neither sure wh= ether it is safe to do so, nor whether CC's -Oz really does much now, consi= dering LTO will be on. > > Any help with understanding the current design is appreciated, thanks! > IIRC DLINK2_FLAGS is mainly being used (in the GCC case) for passing options that need to come after previous occurrences of the same option with a different value, in order for the DLINK2 one to take precedence.