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 14482 invoked from network); 6 Mar 2021 02:09:56 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2021 02:09:56 -0000 Received: (qmail 9781 invoked by uid 550); 6 Mar 2021 02:09:50 -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 9760 invoked from network); 6 Mar 2021 02:09:49 -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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WDk5IDVBOo0+JGwmV2Q5rPUyM23LJbrZvegg+nts5r8=; b=hJjZjXdMzIycXiWnNAYh3jpod+QIr5Ah3WqlHnWFfIBAq50iiAKN8EqpIYZOsJ6Xzc UUthZsUS30rXsEzztMgmTfPCOsCun3IObMSsdOKH7gVlEBUgWhmf74vCCN0heKcatv71 d5Seqc19AYMsEgO+cj/Cq4Lzes/osdRSe2qq/0NTAuZs3AM3pZiktQmqsKVIJxTRq4YR Otp9VPQ+B3AdsGKudRHXeo/4BRj7TRpuMfF/YscrKDKPmVuLGF9oHiKi5yf8OFYOnwM5 CuhtLs1wrSmpO4coX8sTj189+n2PGNwTXw5DQWsCT19d8nQywEDBKpfvFI0eOJcWjQdb 2lwg== X-Gm-Message-State: AOAM532n+X4Z3H/1qf4s7vIAaalG14zh23tmCjjuiVH2uWHNkCPD5jc3 m9RaidHDcEQlY0xvw/R7G4/KxEYC/U4= X-Google-Smtp-Source: ABdhPJysaRGIW/Ew+HSQ3GgrNrA6js2Rfv1jfMFjjTCTVZ2aQFrEIDaVSqmr7itYVpHdfqMhSEh0Fg== X-Received: by 2002:a63:2948:: with SMTP id p69mr11144797pgp.15.1614996577715; Fri, 05 Mar 2021 18:09:37 -0800 (PST) Date: Fri, 5 Mar 2021 18:09:36 -0800 From: Fangrui Song To: musl@lists.openwall.com Message-ID: <20210306020936.45kirg5cbj6d5aks@gmail.com> References: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> <20210305150730.GN32655@brightrain.aerifal.cx> <20210305161256.GO32655@brightrain.aerifal.cx> <20210306011405.g5t2pncdcbh4ebij@gmail.com> <20210306013902.2rec4xrbg4j5mikf@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: >> 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 > >There is no .eh_frame in any of the object files involved (neither t.o >or crt*.o), just in the final executable. It seems that GNU ld creates >a .eh_frame section unless you pass --no-ld-generated-unwind-info. > >> 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. > >Which files are you interested in? The recipe I showed earlier should >be sufficient to reproduce the issue. You can use the standard alpine >linux toolchain (using /usr/lib instead of /lib for the paths to the >crt*.o files). With a musl.cc toolchain, you'll need to pass -z >separate-code to get the empty PT_LOAD segment, but the empty >.eh_frame is there either way. You can build ld from the upstream binutils-gdb repo. after configure, run `make -j30 all-ld` and use ld/ld-new. If you can reproduce, p_memsz==0 PT_LOAD in -z separate-code case deserves a bug.