Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3464673pxu; Tue, 15 Dec 2020 07:38:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJxzz8eyNh7KEoqCQr0i8GQJM0o22LItm4UwLkceg18kaZHTL3aO+3YUuaKR42x5Y8F1z6La X-Received: by 2002:a17:906:90d6:: with SMTP id v22mr27589609ejw.88.1608046714075; Tue, 15 Dec 2020 07:38:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608046714; cv=none; d=google.com; s=arc-20160816; b=Ap5JVHb8OJj+bc1Expiv38bFHYpLydiyKQf9fq/hZ/ZDcz30Szh0HnbdZ8romilAYJ eMSb/ubeubcTxmkm3wCaipaUJJWkGxK5m1a4qHZeNxu/QZscJGxu0I3HrvZkZ/VXyA61 yihxpBbGwLDgH5XRrn1FQNCDbRE5zudKTNd5JaSginOIVrytEZLewB1k85DCb51eIXpy tQTymYm23mJUR6Idp8Dlvys60M/Rj2lbleuUt3aN5Q79vWVU1nv4MgUDXtJkxYc0ZNkP NF/+T1a5xYsRc/+HL5mY3fxBR4tlFxWELFcgvc4FWqsItbSk3fz7COQwB+4uUGVD8i2t eiLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=IJrM3CD2Z+mCiZKNkObq5Jaq/e82BoHOW6QRha3ydX4=; b=osXwqe5OXY7+9cpdvwwed2maturSUB/YF+h+lNuzmEezj3dIOz2MfDN0/LlasaFt7h fj9BFrYx2rMYjbuFEhZkLBTXRALjYw4kFfiRxe7adnVzQHK9Uq4h8IY+X/+zbHO5H8va lYIWLeIqLLUS7aWla+sPbvvK7TGbTygMxJAR2FtrYfqj+aoCfM5RU7uCXLiPw4vVnSnF GssUC3Q55mnUv0UIJx7wGMae55dnt2JcfEDCloxU3mgfXOe3h7DhU8z4YUjeSJA9o7yj vpMOGF93ysMHrnJ3eX3SVKEcVyOInGZn5WJtgwKJ7WL0E+mj3Vu6U0pQoXpxQeeVYize jEWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ojTqYk0a; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t10si1030764eju.346.2020.12.15.07.38.09; Tue, 15 Dec 2020 07:38:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ojTqYk0a; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730020AbgLOPfp (ORCPT + 99 others); Tue, 15 Dec 2020 10:35:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:36018 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729723AbgLOPf0 (ORCPT ); Tue, 15 Dec 2020 10:35:26 -0500 Date: Tue, 15 Dec 2020 12:34:48 -0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608046476; bh=52A4ekBlPoxabGGEHzBDiC3rCXzZ5CrR7GUKzWMiBHs=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=ojTqYk0a8J2vXMXc7L/cIs8bYOvF+eiHlWQVneN8dCUhUUqzf32813BCfcJUfh6e6 MJ5lDkyU6uurS8rf5vIXa0Y9u/9k3cxJkdUNgZuDGiqm2idYdfxzB6ETx2Fd35co8J 98YUsk4atCti3ArXWVK1enMWLmGcbYI74lP/HWtv64s93xgG3+2yiilrcbMjUl08fE vogE1iVsC8I1J3I5P+QSCmzu3mJ9TxE/t/zXrJ8lsSv86B3mcIButCybtO3hXwMljN OuG0Uld+OiNgX7mAC8riPutfrUdzmZ5ugptbvQ6SZk1PIeKctDGzooBGEA1sG6uodf H5+FpOBhS8hpQ== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Tiezhu Yang , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , linux-kernel , Xuefeng Li Subject: Re: [PATCH v2] perf callchain: Return directly when use '--call-graph dwarf' under !HAVE_DWARF_SUPPORT Message-ID: <20201215153448.GA258566@kernel.org> References: <1607996131-9340-1-git-send-email-yangtiezhu@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, Dec 15, 2020 at 10:49:59PM +0900, Namhyung Kim escreveu: > Hello, > > On Tue, Dec 15, 2020 at 10:35 AM Tiezhu Yang wrote: > > > > DWARF register mappings have not been defined for some architectures, > > at least for mips, so we can print an error message and then return > > directly when use '--call-graph dwarf'. > > > > E.g. without this patch: > > > > [root@linux perf]# ./perf record --call-graph dwarf cd > > Error: > > The sys_perf_event_open() syscall returned with 89 (Function not implemented) for event (cycles). > > /bin/dmesg | grep -i perf may provide additional information. > > > > With this patch: > > > > [root@linux perf]# ./perf record --call-graph dwarf cd > > DWARF is not supported for architecture mips64 > > > > Usage: perf record [] [] > > or: perf record [] -- [] > > > > --call-graph > > setup and enables call-graph (stack chain/backtrace): > > > > record_mode: call graph recording mode (fp|dwarf|lbr) > > record_size: if record_mode is 'dwarf', max size of stack recording () > > default: 8192 (bytes) > > > > Default: fp > > > > Signed-off-by: Tiezhu Yang > > --- > > > > v2: Use HAVE_DWARF_SUPPORT to check > > I'm not sure whether this is because of lack of dwarf library or kernel support. > Based on the error message, I guess it's from the kernel. Then I think this > patch won't be sufficient.. tools/perf/Makefile.config ifndef NO_DWARF ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined) msg := $(warning DWARF register mappings have not been defined for architecture $(SRCARCH), DWARF support disabled); NO_DWARF := 1 else CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS) LDFLAGS += $(LIBDW_LDFLAGS) EXTLIBS += ${DWARFLIBS} $(call detected,CONFIG_DWARF) endif # PERF_HAVE_DWARF_REGS endif # NO_DWARF [acme@five perf]$ find tools/perf -type f | xargs grep PERF_HAVE_DWARF_REGS tools/perf/arch/xtensa/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/x86/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/arm64/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/arm/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/s390/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/powerpc/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/sh/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/riscv/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/sparc/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/arch/csky/Makefile:PERF_HAVE_DWARF_REGS := 1 tools/perf/Makefile.config: ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined) tools/perf/Makefile.config: endif # PERF_HAVE_DWARF_REGS [acme@five perf]$ Ouch: [acme@five perf]$ cat tools/perf/arch/xtensa/Makefile # SPDX-License-Identifier: GPL-2.0-only ifndef NO_DWARF PERF_HAVE_DWARF_REGS := 1 endif [acme@five perf]$ So you have a point, only if NO_DWARF is not defined, then PERF_HAVE_DWARF_REGS is can be used to define HAVE_DWARF_SUPPORT, too clumsy. So probably my hunch that this should be done at evsel__open_strerror() and use perf_missing_features.dwarf_regs is what we should go... I'm removing this patch from my current tree, please take a look at: https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf/core&id=f55c66234c1967f6e56e56c3e084f80b417c124b For how I did this for another feature that the kernel may or not support, perf_event_open() fails, it notices that in perf_missing_features and then later evsel__open_strerror() returns a sensible warning, reacting to something the running kernel returned. - Arnaldo