From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id E9FB52299C for ; Mon, 24 Feb 2025 15:02:34 +0100 (CET) Received: (qmail 30075 invoked by uid 550); 24 Feb 2025 14:02:29 -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 x-ms-reactions: disallow Received: (qmail 30047 invoked from network); 24 Feb 2025 14:02:29 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740405741; x=1741010541; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sCeoI3MgBNZr1w4U56nvY8xYtZURYQdXduSD/j/Yyeo=; b=TqRU7A8CnVK+GySeNALPB1I+5uy2aweV93xhYr0QAVu0SGYWDfDs6Na+citrXnrBuu pQbVcxdU/9rpYZ9P/wMdFb483zpyD7LMdS75doH0gxzrzRt5tQmXcefN/gSa1EOj0sp3 E8T6A7ZCTizFlLlaO+8sZwkGjzygwLelYWsoPB8uuiGxc7mw4YcSF5dejTeGY+Hxa0MP 2JmhOjd5MUjwVAlaO+AuEy30B4jDmHA0DW3mz8WVuKZcQxanfGhGvp5k4rEwB85L/1U2 9wCZ7IkS9M8nb89Cp7wu2v1teQs7JWZTFt9ujTscwztjZII8k1WE2dlhBEvzMh8Knbzw pkTA== X-Gm-Message-State: AOJu0YyQSjOVhzhHiSki+OK1y4MsTCZmaRPZ22jrHNmuEv3fc9H61nZc F/IlNFhCnwCMwkUEgJZV3yEVWfNNNfLTkreK1crGFmMDiOST+tN/ X-Gm-Gg: ASbGnct49qPK8+7IpVst5MPb6A9emVT1bF+nUSmojasQk1GsQnuhr9Y4Is1rrJfnith VAQRvkukPt5x5MreJ9z2KCG60CnrtJjEuGNT3ztsphYKJLTkwONw3MjypH/5KP9C4ZiixUtJRpE 2xROa74OUn4thatZNrngC4s4aCT1ujiH0Li0zyKr+Lx9997e0syyRpZI8JiuLVZB7PlOp0CXuYh rsXFB7gGtiIeST4RRnUKsFYAIBrsu9zOY7+HTaT5IH8JGO5EUsSs2w813Td9oOCuC4jWWx9htjI U4FJjOQDu+RluuVKyXA574nqXsjlj9RYamu0SBBEMGhJEnnAS10Bbqun5XyL X-Google-Smtp-Source: AGHT+IFLPmFd1FMmYtm1FJ5UguNtD3R2wNYTxmfHXmQ8ujxaP++HKe3LbTTnJJr6K7b5Sz/gIOGdeA== X-Received: by 2002:a05:6512:31d2:b0:546:2ff9:1542 with SMTP id 2adb3069b0e04-54838f79e55mr4831885e87.53.1740405737540; Mon, 24 Feb 2025 06:02:17 -0800 (PST) Date: Mon, 24 Feb 2025 16:02:14 +0200 From: Timo Teras To: Ivan Trofimov Cc: musl@lists.openwall.com Message-ID: <20250224160214.0cafdcad@onyx.my.domain> In-Reply-To: <4d2f1ada-2f31-4b44-a30d-dbccb97feba1@yandex.ru> References: <4d2f1ada-2f31-4b44-a30d-dbccb97feba1@yandex.ru> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.48; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] [PATCH] x86_64: Generate an eh-frame entry for syscall_cp On Mon, 24 Feb 2025 16:35:54 +0300 Ivan Trofimov wrote: > Some eBPF-based profilers > (open-telemetry/opentelemetry-ebpf-profiler, yandex/perforator, > parca-dev/parca etc. at github.com) leverage eh-frame section to > unwind the stacks of native executables in kernel context. > > This approach works pretty well most of the time, but sometimes fails > to unwind through hand-written assembly due to it missing cfi-* > directives. Usually it's not that big of a deal and doesn't change > the whole picture much, however with musl things are different, since > these unwinders fail to unwind syscalls back to userspace, as musl > doesn't generate an eh-frame entry for __syscall_cp function. Musl has tools/add-cfi.* files to add the cfi annotations programmatically. However, .eh_frame is intentionally turned off, and the cfi ends up in .debug_frame only. I earlier tried to get some .eh_frame enabled, but that led no where and I got no responses on what could be done to enable this for profiling purposes. Basically the response was that .eh_frame enables throwing exception through C library which is UB and intentionally not supported, and that it bloats the LOAD segment size for no good reason. See also eg. https://www.openwall.com/lists/musl/2021/07/16/1 probably there's some other threads also. I wonder if the newer GNU .sframe would be something that can be enabled? Rich, any comments on enabling .sframe generation? It would not enable throwing exceptions etc., and is smaller in size. > Imagine a flamegraph, where all (or most) of the syscalls are > completely out of place: this is the problem this patch aims to fix > for x86-64. Because of the above, opentelemetry-ebpf-profiler supports also .debug_frame directly in the .so and in detached debug files. Try installing musl debug data file (if available) and things will start working a lot better. Timo