From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 289E73858C2C for ; Mon, 3 Jan 2022 13:05:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 289E73858C2C Received: by mail-pf1-x434.google.com with SMTP id b22so29364001pfb.5 for ; Mon, 03 Jan 2022 05:05:31 -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=7l5w6/OvRbPUuwjr5Rwg3N0+qdb+rCxHRa0Jpj+it4g=; b=xCerm52Ff4ruVb46qrsIttejTSOjSKQIhpaQGybBiAHXkfeoEnsrdyNLXoBJXclW5W kyCy4YItN2XJUnxWoPkrO42YAXu/AHl4nSfJlPbs6vY78VtF12/ZYRF0JWFam365eTy1 Jr+2ut0M6Wk9+N9nliAnuIBBSGw23oWYCK2qjKzHldcivjjOBqx2wRULFy47/Pp6luJA b2E3mSPfw7iAI3pLGVVmy/b4t6Zw8g6G3OEo8jZyPwXcOx6FNykXoqvRorx4Sl8MZRx/ AWfH3+0uV5BwUPbEX7F6uvlNDYuvpKM7L/syYfdOjnxVKs+b1F2Hjp+gQiHDPkCZuPHT zFYA== X-Gm-Message-State: AOAM530NlmzZ1Tw/W8Vwv7jZhWRH0IWRxJwi5tw3WEUUUZOeRumsmcPI w8LH1F3oOkzv2hOdaGqkPKc2Y3ADk9+TedKMhBeUK5YK X-Google-Smtp-Source: ABdhPJyG7rUlXUqTdvRGTcSpYZt0KH1b0sKVWtK1eJiAtIhrYoK60P6XcslBnmFLvm/lnPicbQYdG41OIdYmN7NEuMc= X-Received: by 2002:a63:e50b:: with SMTP id r11mr39924007pgh.210.1641215130271; Mon, 03 Jan 2022 05:05:30 -0800 (PST) MIME-Version: 1.0 References: <875yr1j90u.fsf@oldenburg.str.redhat.com> <871r1pj871.fsf@oldenburg.str.redhat.com> In-Reply-To: <871r1pj871.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 3 Jan 2022 05:04:54 -0800 Message-ID: Subject: Re: ELF LOAD segments creating holes in the process image on GNU/Linux To: Florian Weimer Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3022.1 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, 03 Jan 2022 13:05:32 -0000 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? -- H.J.