From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2D0F03858C2C for ; Mon, 3 Jan 2022 13:14:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D0F03858C2C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-442--SQIucS5MCC0LJ45U4td3w-1; Mon, 03 Jan 2022 08:14:23 -0500 X-MC-Unique: -SQIucS5MCC0LJ45U4td3w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EDCC62FD1B; Mon, 3 Jan 2022 13:14:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.102]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FE6610840C4; Mon, 3 Jan 2022 13:14:21 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: Binutils Subject: Re: ELF LOAD segments creating holes in the process image on GNU/Linux References: <875yr1j90u.fsf@oldenburg.str.redhat.com> <871r1pj871.fsf@oldenburg.str.redhat.com> Date: Mon, 03 Jan 2022 14:14:20 +0100 In-Reply-To: (H. J. Lu's message of "Mon, 3 Jan 2022 05:04:54 -0800") Message-ID: <87v8z1hsgj.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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, 03 Jan 2022 13:14:26 -0000 * H. J. Lu: > On Mon, Jan 3, 2022 at 4:49 AM Florian Weimer wrote: >> >> * H. J. Lu: >> >> > On Mon, Jan 3, 2022 at 4:31 AM Florian Weimer via Binutils >> > wrote: >> >> >> >> At least on x86-64 on GNU/Linux, for PIE and non-PIE binaries, LOAD >> >> segments are not always contiguous. The triggering conditions are not >> >> quite clear to me. >> >> >> >> For ET_EXEC (non-PIE) executables, I think this is a supported feature, >> >> and the kernel and glibc dynamic loader handle this the same way, >> >> creating holes. However, these holes make dealing with the main >> >> executable slightly more complicated in some cases (e.g., we can handle >> >> contiguous mapping slightly more efficiently when looking objects based >> >> on addresses). Holes also make page tables less compact (although that >> >> effect is probably minuscule). Abstractly, I don't see a reason why the >> >> link editor has to create such holes on the most common targets. (I >> >> have heard that ia64 really needed those holes.) >> >> >> >> For ET_DYN (PIE) executables, we have a Linux vs glibc difference: The >> >> Linux loader creates holes as well, while the glibc loader refuses to >> >> create them and fills them with a PROT_NONE mapping from the executable. >> >> >> >> Is this something we could fix in ld? >> >> >> > >> > Is it created by -z separate-code? >> >> I believe so because it is the default? > What do you want linker to do? Ideally? p_offset, p_vaddr, p_filesz, p_memsz should all be multiples of the page size, to closer reflect what can actually be loaded. Then, for each LOAD segment, p_vaddr plus p_memsz should be equal to p_vaddr of the next LOAD segment. Thanks, Floriam