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 11117 invoked from network); 6 Mar 2021 01:39:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2021 01:39:19 -0000 Received: (qmail 28588 invoked by uid 550); 6 Mar 2021 01:39:17 -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 28570 invoked from network); 6 Mar 2021 01:39:16 -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=tluAnVqDo2eWBjmPC1KziVz0k+A8AAc7EnvE8yCRPP0=; b=TbF+wKvVqk0UngaWvNFHwhhErmLXa+PSuzK4jqrK7h9bGDmtHhoAxsV/yHT8KN8IbD Mj10sMq0Lrt9/E2WRlwBpGo+0l3256pQkyzL1Fh0ZWdXR84KzAAiEy7/v1EeXyzq90cQ e5l++T8YlR+S+XkY3nsG/tfnyhb8jE+qVHIoN9tZtbQobocRTdDMmucY0Fc5P7mB4E9u Iw+akOqf818C3ZVBY+nSDWaGl2hMvgZxNSceh8d/bQM1qx9m4AqU7mPDPwcAsAcVeHfK VkPaE1mTTFycfXuF9s5ISF0+purQFMPIdeYTXIZerLyR82qPVVYJCMsteEzS9CR9cTb3 V9TQ== X-Gm-Message-State: AOAM530pmmKdhPyZA12QgIhV8GhB/+awR1y+ng+AXeb4XpY3I4TZ+76b FDwUVsDFjLCNZZBolr3JWv29tcPyOPw= X-Google-Smtp-Source: ABdhPJyznjt7lKRfM+QmWtNwin/FAARo6V965L09wQo4FU7nqMYoNNPnnKuSO1L0FhlSEoUDq1Vt+A== X-Received: by 2002:a62:7ac3:0:b029:1f1:5d13:5ec6 with SMTP id v186-20020a627ac30000b02901f15d135ec6mr4342139pfc.14.1614994744222; Fri, 05 Mar 2021 17:39:04 -0800 (PST) Date: Fri, 5 Mar 2021 17:39:02 -0800 From: Fangrui Song To: musl@lists.openwall.com Cc: Rich Felker Message-ID: <20210306013902.2rec4xrbg4j5mikf@gmail.com> 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; 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, Fangrui Song wrote: >> Can you clarify how GNU ld creates an empty .eh_frame? > >Sure, see the shell snippet in my original post. > >> 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 > >There is no PT_GNU_EH_FRAME in the executables. Based on Rich's >explanation earlier, my understanding is that the issue is that GNU ld >creates a empty PT_LOAD segment for the empty .eh_frame section. > >I attached the output of readelf -l in case that is helpful. > >> 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 empty PT_LOAD segment is the issue here, not PT_GNU_EH_FRAME. > >> 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 you saying that GNU ld might create PT_LOAD segments with zero >size, and unaligned p_vaddr? If that's the case, I think Rich might >have a valid concern here. p_memsz==0 PT_LOAD is invalid. ld.bfd -z separate-code should not create such PT_LOAD. But this is more of implementation convention (many libc implementation error on this case or mmap will fail), not something regulated by the specification. (In LLD, we drop such PT_LOAD: https://github.com/llvm/llvm-project/blob/main/lld/ELF/Writer.cpp#L163) The empty .eh_frame is suspicious, though. There may be two problems: 1. Why do you have an empty .eh_frame in an object file 2. Why does ld.bfd create empty .eh_frame in that case (I have tried simple examples like `.section .eh_frame,"a"` and I cannot reproduce the empty output .eh_frame) If you don't share the other files, it is difficult to locate the problem. 2. deserves a http://sourceware.org/ bug. > >Elf file type is EXEC (Executable file) >Entry point 0x401020 >There are 9 program headers, starting at offset 64 > >Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 > 0x00000000000001f8 0x00000000000001f8 R 0x8 > INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238 > 0x0000000000000019 0x0000000000000019 R 0x1 > [Requesting program interpreter: /lib/ld-musl-x86_64.so.1] > LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 > 0x0000000000000348 0x0000000000000348 R 0x1000 > LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000 > 0x0000000000000060 0x0000000000000060 R E 0x1000 > LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000 > 0x0000000000000000 0x0000000000000000 R 0x1000 > LOAD 0x0000000000002e90 0x0000000000402e90 0x0000000000402e90 > 0x0000000000000190 0x0000000000000190 RW 0x1000 > DYNAMIC 0x0000000000002e90 0x0000000000402e90 0x0000000000402e90 > 0x0000000000000160 0x0000000000000160 RW 0x8 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 RWE 0x10 > GNU_RELRO 0x0000000000002e90 0x0000000000402e90 0x0000000000402e90 > 0x0000000000000170 0x0000000000000170 R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 > 01 .interp > 02 .interp .gnu.hash .dynsym .dynstr .rela.dyn .rela.plt > 03 .plt .text > 04 .eh_frame > 05 .dynamic .got .got.plt > 06 .dynamic > 07 > 08 .dynamic .got