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 8490 invoked from network); 6 Mar 2021 01:14:26 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2021 01:14:26 -0000 Received: (qmail 17917 invoked by uid 550); 6 Mar 2021 01:14:20 -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 17896 invoked from network); 6 Mar 2021 01:14:19 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=SJUubK+LBFwE8wzr5L5LiwnKut7G0JzC7+Fd+uEOfCo=; b=q/wmkwQ4F2gwWEgxwTy5cuOUyFGZ82MFxIF3PsFawx0t4wO/L/MmK83LRo8JRubLQm YDjTxtWpytMTvLWzrPz0Y2mmkMqMbuJkzECHreSLL7HNdGB7Keo/gfGn6VNh5fyfCkiT 7IqeJKzNw/JFeAoYrwn3Tm05W3LRMjrfP4u/HmpLyTjArg1kPd69GmHjetPlV0xcGHYY 7r5ZVlZWv6BBUuXGhmUB/FT9+Ju+UTutFg/1gfPyouNMl2LyL4swdprWngqudsbHbANn 5J3B57sc7PD2whIc5qLj8HuBPdJfxByqB8YrhlF/qIba3bQisQGzFoZRAdOV6PqbGN3y 4Rng== X-Gm-Message-State: AOAM53278/vkIfmj565cXsAIfcZj0vdfx3wso/gePpEAs8MaH2L7mb0j /Qkw9zVYi/hkzfhCo9EYaZoYzyd0P20= X-Google-Smtp-Source: ABdhPJxoSmdkbjYSXuYX0xJkJipa0rNQE2AxZGFItiPLtuP9UMW2o3uG7EmO1CIvKYyKUUqVGqVraA== X-Received: by 2002:a63:f953:: with SMTP id q19mr10724100pgk.125.1614993247446; Fri, 05 Mar 2021 17:14:07 -0800 (PST) Date: Fri, 5 Mar 2021 17:14:05 -0800 From: Fangrui Song To: musl@lists.openwall.com Cc: Rich Felker Message-ID: <20210306011405.g5t2pncdcbh4ebij@gmail.com> References: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> <20210305150730.GN32655@brightrain.aerifal.cx> <20210305161256.GO32655@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Subject: Re: [musl] ld-musl-* and empty .eh_frame 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 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.