From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44B93C433E7 for ; Thu, 8 Oct 2020 09:38:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC36A20725 for ; Thu, 8 Oct 2020 09:38:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729021AbgJHJiC convert rfc822-to-8bit (ORCPT ); Thu, 8 Oct 2020 05:38:02 -0400 Received: from wildebeest.demon.nl ([212.238.236.112]:43594 "EHLO gnu.wildebeest.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726019AbgJHJiC (ORCPT ); Thu, 8 Oct 2020 05:38:02 -0400 X-Greylist: delayed 328 seconds by postgrey-1.27 at vger.kernel.org; Thu, 08 Oct 2020 05:38:02 EDT Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E1828300160F; Thu, 8 Oct 2020 11:32:32 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 945F440007BE; Thu, 8 Oct 2020 11:32:32 +0200 (CEST) Message-ID: <50338de81b34031db8637337f08b89b588476211.camel@klomp.org> Subject: Re: Additional debug info to aid cacheline analysis From: Mark Wielaard To: Peter Zijlstra , Stephane Eranian Cc: linux-toolchains@vger.kernel.org, Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Ingo Molnar , Jiri Olsa , Namhyung Kim , Ian Rogers , "Phillips, Kim" , Mark Rutland , Andi Kleen , Masami Hiramatsu Date: Thu, 08 Oct 2020 11:32:32 +0200 In-Reply-To: <20201008070231.GS2628@hirez.programming.kicks-ass.net> References: <20201006131703.GR2628@hirez.programming.kicks-ass.net> <20201008070231.GS2628@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org Hi, On Thu, 2020-10-08 at 09:02 +0200, Peter Zijlstra wrote: > Some time ago, I had my intern pursue the other 2 approaches for > > symbolization. The one I see as most promising is by using the DWARF > > information (no BPF needed). The good news is that I believe we do not > > need more information than what is already there. We just need the > > compiler to generate valid DWARF at most optimization levels, which I > > believe is not the case for LLVM based compilers but maybe okay for > > GCC. > > Right, I think GCC improved a lot on this front over the past few years. > Also added Andi and Masami, who have worked on this or related topics. For GCC Alexandre Oliva did a really thorough write up of all the various optimization and their effect on debugging/DWARF: https://www.fsfla.org/~lxoliva/writeups/gOlogy/gOlogy.html GCC using -fvar-tracking and -fvar-tracking-assignments is pretty good at keeping track of where variables are held (in memory or registers) when in the program, even through various optimizations. -fvar-tracking-assignments is the default with -g -O2. Except for the upstream linux kernel code. Most distros enable it again, but you do want to enable it by hand when building from the upstream linux git repo. Basically you simply want to remove this line in the top-level Makefile: DEBUG_CFLAGS := $(call cc-option, -fno-var-tracking-assignments) Cheers, Mark