From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 681313858C60 for ; Mon, 20 Dec 2021 18:40:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 681313858C60 Received: by mail-pj1-x1032.google.com with SMTP id k6-20020a17090a7f0600b001ad9d73b20bso745083pjl.3 for ; Mon, 20 Dec 2021 10:40:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ACDagfvg+uxPWYbmaHEDXH05+JlMdP7HGaTQWfgCTS0=; b=BKln1dbuuIOshRJ6JdMmY6co2sDGwrLHOBmZUiqfq38AoYgMP9v/7JMiXoiMT5KsGb ca9oNAJb47qMPo6MskpXVNIDmqX7E7cjysKgT5dkJz1wQEqFwVac/sp052vce0aUAiIP +cYYXoyRpuM7xRJcJKKkcFqabToUucL6UN5nql1Sy2UTlDH8G/SXxRtlZuoO3S/6dR4A UsB78MLU6vpXYplXpowg+SG8yWpP59DR0dKDgeoaRuG4GGVbAJlpYI3LZ+pl3BujC9GB yD84a7Ug7eZ/NUZxNXtFUftJvQpQZNMTMxB2CNE8Qe1BEl2TmYU8MC1LfCmyFf0dhD3j WTUw== X-Gm-Message-State: AOAM533ZFjTtrjII8KBE9ItSLjHf5Jo8Btjig0R8KNkmyk82dPX6VlzS GUA6y/k4WwTdhXgJuQDzG706OYg1T2+eejHgGRg= X-Google-Smtp-Source: ABdhPJzH8CueQAaMd9H0Fdr/5dsBYyWGMmH9lxN5de/H9y3rm4IsiL4Qv0AL6Uv8DY+ipIseXC76WaACylyTQsloPhs= X-Received: by 2002:a17:90a:74f:: with SMTP id s15mr340093pje.120.1640025616445; Mon, 20 Dec 2021 10:40:16 -0800 (PST) MIME-Version: 1.0 References: <20211215163232.1787673-1-hjl.tools@gmail.com> <20211216085252.3jgtc6an6x5wlfzs@gmail.com> <87zgovfd2u.fsf@oldenburg.str.redhat.com> In-Reply-To: <87zgovfd2u.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 20 Dec 2021 10:39:40 -0800 Message-ID: Subject: Re: [PATCH] elf: Set p_align to the common page size if possible To: Florian Weimer Cc: Fangrui Song , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3022.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 18:40:19 -0000 On Mon, Dec 20, 2021 at 8:36 AM Florian Weimer wrote: > > * Fangrui Song: > > > On 2021-12-15, H.J. Lu via Binutils wrote: > >>Currently, on 32-bit and 64-bit ARM, it seems that ld generates p_align > >>values of 0x10000 even if no section alignment is greater than 0x1000. > >>The issue is more general and probably affects other targets with > >>multiple common page sizes. > >> > >>While file layout absolutely must take 64K page size into account, that > >>does not have to be reflected in the p_align value. If running on a 64K > >>kernel, the file will be loaded at a 64K page boundary by necessity. On > >>a 4K kernel, 64K alignment is not needed. > >> > >>The glibc loader has been fixed to honor p_align: > > > > Maybe it's just me who is very careful on the words: aligning to p_align > > is a new feature, not a bug, as no ABI requires it. No ld.so I know > > (FreeBSD, musl, bionic) does this. > > The expectation seems to be fairly clear that p_align should reflect > segment alignment. It's true that the ELF specification does not > explicitly say that segment alignment of virtual addresses also carries > over to the process image, but that part seems so obvious that it > perhaps wasn't stated explicitly. > > Current linkers probably should have used the reserved values 0 and 1 if > they want to convey that alignment does not matter. > > >>https://sourceware.org/bugzilla/show_bug.cgi?id=28676 > >> > >>similar to kernel: > >> > >>commit ce81bb256a224259ab686742a6284930cbe4f1fa > >>Author: Chris Kennelly > >>Date: Thu Oct 15 20:12:32 2020 -0700 > >> > >> fs/binfmt_elf: use PT_LOAD p_align values for suitable start address > > > > This kernel patch has no cost. It just picks a load bias, while the > > glibc's .so loading patch has some costs because there is no alignment > > parameter to mmap... So now, every > > > > * (Linux x86-64) -z noseparate-code (default max-page-size=2MiB) .so incurs some munmap overhead > > * arm/aarch64/powerpc (default max-page-size=65536) .so incurs some munmap overhead... > > > > If I were to do this, I would fix objcopy first, then adjust ld's > > p_align, finally tune glibc's .so loading. > > Maybe we need to add some markup that the p_align value is actually > real. > We need to set larger p_align > sh_addralign for huge page executables. My current algorithm to decide if p_align should be used as the maximum page size for objcopy is static bool elf_is_p_align_valid (bfd *abfd) { unsigned int i; Elf_Internal_Phdr *segment; unsigned int num_segments; const struct elf_backend_data *bed = get_elf_backend_data (abfd); bfd_size_type maxpagesize = bed->maxpagesize; bfd_size_type commonpagesize = bed->commonpagesize; if (commonpagesize == maxpagesize) return true; /* When the common page size != the maximum page size, p_align may be set to the common page size while segments are aligned to the maximum page size. In this case, the input p_align will be ignored and the maximum page size will be used to align the output segments. */ segment = elf_tdata (abfd)->phdr; num_segments = elf_elfheader (abfd)->e_phnum; for (i = 0; i < num_segments; i++, segment++) if (segment->p_type == PT_LOAD && (segment->p_align != commonpagesize || vma_page_aligned_bias (segment->p_vaddr, segment->p_offset, maxpagesize) != 0)) return true; return false; } It should cover all cases. -- H.J.