From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15599 invoked from network); 5 Mar 2021 16:13:15 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2021 16:13:15 -0000 Received: (qmail 13614 invoked by uid 550); 5 Mar 2021 16:13:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13589 invoked from network); 5 Mar 2021 16:13:09 -0000 Date: Fri, 5 Mar 2021 11:12:56 -0500 From: Rich Felker To: Michael Forney Cc: musl@lists.openwall.com Message-ID: <20210305161256.GO32655@brightrain.aerifal.cx> References: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> <20210305150730.GN32655@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210305150730.GN32655@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] ld-musl-* and empty .eh_frame On Fri, Mar 05, 2021 at 10:07:32AM -0500, Rich Felker wrote: > On Thu, Mar 04, 2021 at 07:18:11PM -0800, Michael Forney wrote: > > Hi, > > > > Érico noticed that cproc (my C compiler) produced executables that > > musl's dynamic linker fails to load when passed as an argument: > > > > /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program > > > > However, running ./t directly works fine. It turns out that this > > is because the executables have an empty .eh_frame section, which > > causes musl to attempt an mmap with length 0 which fails with EINVAL. > > The section itself isn't the problem; rather the linker making a > dedicated PROT_READ segment with no non-zero-length sections in it is. > It really should have collapsed that out. (Also it would not happen > without the separate-text option, which mcm disables because it makes > lots of problems.) > > With that said, there's no good reason we should error out on this; > it's syntactically and semantically valid just pointless for the > linker to emit. I think adding if (!n) return p; at the top of > mmap_fixed in dynlink.c fixes it. In practice this probably does, but there's also something of a question what to do if the zero-size segment is not page aligned. This is not actually a mmap error since it will be automatically expanded out to page boundaries in both directions, but if ld is capable of emitting such segments they may be semantically wrong (mapping over top of something else they're not intended to). Can you confirm that ld isn't doing anything awful here? Rich