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 9988 invoked from network); 6 Mar 2021 01:28:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2021 01:28:37 -0000 Received: (qmail 23573 invoked by uid 550); 6 Mar 2021 01:28:35 -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 23555 invoked from network); 6 Mar 2021 01:28:35 -0000 Date: Fri, 5 Mar 2021 20:28:21 -0500 From: Rich Felker To: Fangrui Song Cc: musl@lists.openwall.com Message-ID: <20210306012821.GP32655@brightrain.aerifal.cx> References: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> <20210305150730.GN32655@brightrain.aerifal.cx> <20210305161256.GO32655@brightrain.aerifal.cx> <20210306011405.g5t2pncdcbh4ebij@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210306011405.g5t2pncdcbh4ebij@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] ld-musl-* and empty .eh_frame On Fri, Mar 05, 2021 at 05:14:05PM -0800, Fangrui Song wrote: > On 2021-03-05, Michael Forney wrote: > >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? > > Can you clarify how GNU ld creates an empty .eh_frame? > The program header PT_GNU_EH_FRAME is created from .eh_frame_hdr, which > is created by ld --eh-frame-hdr. > If .eh_frame is empty, from my observation GNU ld does not create .eh_frame_hdr > > https://maskray.me/blog/2020-11-08-stack-unwinding#eh_frame_hdr-and-pt_eh_frame > > >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 > > max-page-size is for layouting PT_LOAD. > It is unrelated to PT_GNU_EH_FRAME. The topic in question is PT_LOAD. > >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. > > The requirement is > http://www.sco.com/developers/gabi/latest/ch5.pheader.html > "p_vaddr should equal p_offset, modulo p_align." > > p_vaddr % p_align != 0 is valid. > > p_memsz can be zero. Are these together valid? In that case, p_memsz==0 but p_vaddr % p_align != 0 would result in mapping an unused page, no? Or is this somehow a special case where the mapping size is not supposed to be expanded out to page-aligned? Rich