lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 08 Oct 2020 11:32:32 +0200
From:   Mark Wielaard <mark@...mp.org>
To:     Peter Zijlstra <peterz@...radead.org>,
        Stephane Eranian <eranian@...gle.com>
Cc:     linux-toolchains@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        "Phillips, Kim" <kim.phillips@....com>,
        Mark Rutland <mark.rutland@....com>,
        Andi Kleen <andi@...stfloor.org>,
        Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: Additional debug info to aid cacheline analysis

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ