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.95398.1680592980414931165 for ; Tue, 04 Apr 2023 00:23:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=odxHuYjt; 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 D2ABD62E5B for ; Tue, 4 Apr 2023 07:22:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48808C4339B for ; Tue, 4 Apr 2023 07:22:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680592979; bh=wN24tCgshdS6U1dq07C5pD3sGDSMz+WUQ4eLtdpRdcA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=odxHuYjt+mdeGjQqQLzf4sGGecidvTIGHaEOfV9zkTcKDpSWQxGDYu8IA3jxtwL3L Gvpwrw3UYov5rrz3IOMqt/cHjKrMyuiyg0tJQpPKHI/T+G7syTaDTWwr0E7ZWjGECI 7eo8RgT5BtSedY3wEB6oKwdiVwFOUfXpqVxd30bABT7OOICBKFr8ElxU3qJbP8u8ed rSfC58YaY0Q5ZXMom8ezazyLjZF0Ne8vZDFlDOWjmMkYnKFF3vUwaVfIgj7qBUsPN2 0K0YvJZkGRYS5LaE4NBxnsAVzmjUSbGcs5F02qDo0fBfZFQoV8iidDbgM2xA6PJxUw P6v91ZyZ8yH6g== Received: by mail-lj1-f175.google.com with SMTP id 20so32816088lju.0 for ; Tue, 04 Apr 2023 00:22:59 -0700 (PDT) X-Gm-Message-State: AAQBX9dMmqS7ygz0Kj+SjxllZ9VlCQZPUczUEWVHwaMIvE8TvmgIIC6d Q7eqSliVYmnHQwnRS0rMwxt2MHR486PcjXD1li0= X-Google-Smtp-Source: AKy350YNz+47O9Y3k2HFBw5z17b0sSQA1lxsJEA1OSykrTUOvU8Nrl2flCrefJ7KY5KBXZ2QG9k4i6l2MJdhSpdfHMI= X-Received: by 2002:a2e:998c:0:b0:2a5:fe8f:ddec with SMTP id w12-20020a2e998c000000b002a5fe8fddecmr691022lji.2.1680592977267; Tue, 04 Apr 2023 00:22:57 -0700 (PDT) MIME-Version: 1.0 References: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> In-Reply-To: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> From: "Ard Biesheuvel" Date: Tue, 4 Apr 2023 09:22:45 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linker scripts use of "-z common-page-size=0x20" etc. To: Rebecca Cran Cc: Pedro Falcato , =?UTF-8?Q?Marvin_H=C3=A4user?= , Liming Gao , Ard Biesheuvel , "devel@edk2.groups.io" Content-Type: text/plain; charset="UTF-8" On Mon, 3 Apr 2023 at 22:33, Rebecca Cran wrote: > > As part of my work on the toolchain definitions, I've come across a > situation where ld.lld fails to align sections correctly, due to it > being invoked via clang with the '-n' option, which causes GenFw to fail > with "Section address not aligned to its own alignment.". > Stupid question: if it breaks stuff, why do you use -n ? > The following messages are printed: > > > ld.lld: warning: -z common-page-size set, but paging disabled by omagic > or nmagic ld.lld: warning: address (0x558) of section .data is not a > multiple of alignment (16) > > I tracked the problem down to GccBase.lds and ClangBase.lds, which have: > > /* * The alignment of the .data section should be less than or equal to > the * alignment of the .text section. This ensures that the relative > offset * between these sections is the same in the ELF and the PE/COFF > versions of * this binary. */ .data ALIGN(ALIGNOF(.text)) : > ALIGN(CONSTANT(COMMONPAGESIZE)) { *(.data .data.* .gnu.linkonce.d.*) > *(.bss .bss.*) } > > I can work around the problem by removing "ALIGN(ALIGNOF(.text)", but > I'm wondering if our use of COMMONPAGESIZE/MAXPAGESIZE is correct. > What do you mean by 'correct'? The intent is clearly to declare the mapping granule size, and for SEC/PEI binaries that execute in place from flash, the MMU page size is not the most useful quantum here. > > We pass in a value of 0x20, 0x40 or 0x1000 to "-z common-page-size" with > 0x20 being the most common value. > > Given the page size of the target will never be 32 bytes, the following > comment on https://reviews.llvm.org/D61688 makes sense: > > > "There is at least one linkerscript in Tianocore edk2 that (ab)uses -n > -z common-page-size=0x20 to use CONSTANT(COMMONPAGESIZE) as if it were a > preprocessor macro set with -D in the compiler. The usual approach to > this is to pre-process the linkerscript." > 'Page size' is highly context specific, and toolchain people are (imho) usually quite quick to call something abuse if it does not match their narrow definition of how a compiler or linker should be used. For the same reason, it has been so difficult to get a compiler to understand that the desire for position independent code does not imply that we want GOTs, or care about ELF symbol preemption or copy-on-write footprint of relocatable segments. In general, the bare metal use case (which includes EFI) is quite poorly understood by many people working on toolchains. > > I'm wondering what the correct approach is here: should we do something > similar to how we set PECOFF_HEADER_SIZE and define a SECTION_ALIGNMENT > symbol? We cannot, that is the reason for using the page size switches here: using a symbol to set the location pointer is fine, but using a symbol to set the alignment of a section is not. > Or, as discussed on Discord should we just use > CONSTANT(MAXPAGESIZE) and ignore how it's normally used to specify the > maximum allowable page size for an executable? > Note that (when I last checked), the only effect of setting -z xxx-page-size is that those macros assume the associated value in the linker script. Nothing else in the linker changes behavior (with the exception of the warning you are seeing) So claiming abuse because the provided value does not match the page size of an OS that might also run on the same system is strenuous, and I think our use of it is fine. AIUI, the reason for having ClangBase.lds in addition to GccBase.lds is the fact that LLD does not support common but only max page size, so I think it should be fine to merge the two, and use max-page-size everywhere.