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=DKIM_SIGNED,DKIM_VALID, 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 26073 invoked from network); 5 Mar 2021 22:53:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2021 22:53:58 -0000 Received: (qmail 30480 invoked by uid 550); 5 Mar 2021 22:53:55 -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 30462 invoked from network); 5 Mar 2021 22:53:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uDMFm/hOfgSabUBwCKvms8OpIiyuokL8IzIsPZO3nno=; b=oj1+nPh/cyz4NkKio6f37lBbMidB0S/h06L1RL5eaHZ1weu6dS8SZgaRcx/MMB083g XcXZyZf+kguqa0UvFzg0+t6nw0XWWlSpYWunwJE4CZmuHc2DBK+R+U1/5yCM6Jeiaq7S 0miigColb+b8J9Y4vTDQrTXWwG37SRCY0YUcr712ljTTAM/pHhCdK9m760olfo2du5Z6 zW+x84MMofZ5c4irhjEeThcVhEg6c37D6HuWkYfRZLZ+c6AkJZXodX/iyAcx0quFTLfA /yUSXqWkPLUkWrcliVarxZldkcn6nntatnQl2Jc7RRsGLDWIz94wIgNJvEvoV2+lsYrW T6sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uDMFm/hOfgSabUBwCKvms8OpIiyuokL8IzIsPZO3nno=; b=khcF7BBrWFQXqmVVdhII4OxFqkzbJthrdmjRT33Pd2EI+xKPrJlafgG+Bef3WLxfmH VzvwKm0O/2U+6b6J8UrPmVZqMImmr1CGcv/0M2bCHFtJRYGe0cYlvmYb0BPGBRyoIVBa w6xuQL2bhcYv6tdN43nEmdnydGKhXxBtpVjE0yS0mVmJ8CRTzBW9fI84i24nwMdQmLEj pBRgQZklFPl5DnscrLz6JQHWSCKR6KmD/9OmGLt8r13bnxmZ0SN76cRPCWv+m8AJKgDP 5uNCgjPmhZdJx7Dwdqt3JZAyyjTeJ3aNSWVv6+4oLxCaTeKZljsRkhUqusdMy0cd7ejK 6gwA== X-Gm-Message-State: AOAM530yKvhC6NwytxjO9UNHm6Ld1l5oNXvwIkJkVmwC/UvPkMuKDkx/ ZkrrLtbrdqeMkZSQEULhbyOV98EoRTuc+pJ2hjFtfQ== X-Google-Smtp-Source: ABdhPJw2dMBIoaIl/oJ2wFLRWG7Mt/nF6YPe4Yym48iBh5DZEvFDa7YidqzVhVLk9J13TbWs1OLHwN7QmUQsO512tQ4= X-Received: by 2002:a25:d4c8:: with SMTP id m191mr17152067ybf.426.1614984822606; Fri, 05 Mar 2021 14:53:42 -0800 (PST) MIME-Version: 1.0 X-Originating-IP: [73.70.188.119] In-Reply-To: <20210305161256.GO32655@brightrain.aerifal.cx> References: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> <20210305150730.GN32655@brightrain.aerifal.cx> <20210305161256.GO32655@brightrain.aerifal.cx> From: Michael Forney Date: Fri, 5 Mar 2021 14:53:41 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] ld-musl-* and empty .eh_frame On 2021-03-05, Rich Felker wrote: >> 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.) Ah, that makes more sense. It explains why my attempt to strip .eh_frame from the executable did not have an effect; only stripping it from the objects before linking fixed the issue. >> 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? I'm not too familiar with the binutils codebase, but I can try. As far as I can tell, the alignment is set to at least the maximum page size: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=84a5d942817a9a54b1170fbbb594787c5839aa54;hb=f35674005e609660f5f45005a9e095541ca4c5fe#l5601 The offset to make p_vaddr page-aligned is computed here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=84a5d942817a9a54b1170fbbb594787c5839aa54;hb=f35674005e609660f5f45005a9e095541ca4c5fe#l5622 and p_vaddr is adjusted here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=84a5d942817a9a54b1170fbbb594787c5839aa54;hb=f35674005e609660f5f45005a9e095541ca4c5fe#l5688 So it seems to me that these segments will be page-aligned, but it could very well be the case that I am not following the code correctly (or I am just looking at the wrong part of this 13k line file). Someone more familiar with binutils should probably confirm.