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 10723 invoked from network); 24 Jul 2021 23:46:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jul 2021 23:46:10 -0000 Received: (qmail 17915 invoked by uid 550); 24 Jul 2021 23:46:07 -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 17894 invoked from network); 24 Jul 2021 23:46:06 -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=J00yNlx++PslVdUzf4V3i3NnKSzbRK8+cNh92vvpmwM=; b=V7lEHABRXrAU0UhHIW9zo9bw3PhzogYW6w1Nyo97paa0HLM6nrZZZ9IYnktRBjWHyq AVv530e5FeCLfxaoa1qOGWFNY0c86IbnmSjmBlvxmenM9u7spvTMTjzrKeDEDxaJ/Ng6 ZW66F6FanAbsTe6SVOnztta/Z4D9FzIyWxpQ8fUMRqNNiYIh8Het+ZidHeBe0d+u/dtc 4hNVuLw7dxPD0OMhhVX8xd+3zbKgKX3sb8XuBr/dtpaLcEcVAEXUFG9EssbDyUw1IdC0 r6hE0p3udLAZrrwUpr3VTUHmlCkzOurc2QCKf9vRWDMye0s2DY0xxeej7QOe64FH6ZOl 6UsA== X-Gm-Message-State: AOAM532VIWR+QNn5SWfAIoLA9TNV87DQmInWjftIpLljaN5rstrXaJAr H7zxr8991g5nCrmIe9G9JsqE5AZCu1Q= X-Google-Smtp-Source: ABdhPJyWZKu8W2UezuuaP4tAxNF7Sn413v7l9AIo/2rrUxsjjUmu/3ThdK9S0NJpIrMaNYhAoHGpjQ== X-Received: by 2002:a65:63d0:: with SMTP id n16mr1499226pgv.432.1627170354440; Sat, 24 Jul 2021 16:45:54 -0700 (PDT) Date: Sat, 24 Jul 2021 16:45:52 -0700 From: Fangrui Song To: musl@lists.openwall.com Cc: Rich Felker , Ariadne Conill Message-ID: <20210724234552.v43fcviw5igtpej3@gmail.com> References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> <20210717132543.GG13220@brightrain.aerifal.cx> <20210717184010.246e7895@vostro> <20210717160936.GH13220@brightrain.aerifal.cx> <7aebea1d-b662-75c4-14cb-b614ff1aac9f@dereferenced.org> <20210717235635.GI13220@brightrain.aerifal.cx> <20210718090922.635b96f8@vostro> <20210718102007.0b40e53b@vostro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210718102007.0b40e53b@vostro> Subject: Re: [musl] option to enable eh_frame On 2021-07-18, Timo Teras wrote: >On Sun, 18 Jul 2021 09:09:22 +0300 >Timo Teras wrote: > >> I do have some technical reasons why I'd prefer .eh_frame (getting it >> on core dumps). Fortunately I need these from development boxes where >> I can have custom build for internal use only. So if .debug_frame is >> needed for peace, then so be it. > >I'm trying to implement this currently, and have two observations: > >1) musl.so seems to have .eh_frame even with default options currently. >GCC insists generating it for the PLT. Though otherwise it's empty. >This is on gcc 10.3.1. ld can generate .eh_frame pieces for PLT entries on x86. GNU ld and gold have implemented --ld-generated-unwind-info. It was proposed in 2011 in https://sourceware.org/bugzilla/show_bug.cgi?id=12570 At that time gdb could not unwind from the middle of a PLT entry. (It can do that now.) (ld.lld doesn't have the feature. Considering that only asynchronous unwinding requests in the PLT code sequence may benefit from the feature, this is of very low value. It adds complexity due to breaking phase ordering in a linker.) >2) .debug_frame is 109944 bytes, while .eh_frame_hdr + .eh_frame is >83832. The size difference seems to be because of CIE entries not being >merged for .debug_frame. Yep, ld can optimize .eh_frame_hdr + .eh_frame . .debug_frame is unoptimized.