linux-kernel - Re: [PATCH v9 3/3] perf annotate: LLVM-based disassembler

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]

Message-ID: <ZtXRxYE5WM1vScoT@x1>
Date: Mon, 2 Sep 2024 11:55:01 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>,
	"Steinar H. Gunderson" <sesse@...gle.com>
Cc: linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	irogers@...gle.com
Subject: Re: [PATCH v9 3/3] perf annotate: LLVM-based disassembler

Cc'ing Namhyung, see below.

On Mon, Sep 02, 2024 at 11:53:55AM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Jul 19, 2024 at 05:00:51PM +0200, Steinar H. Gunderson wrote:
> > Support using LLVM as a disassembler method, allowing helperless
> > annotation in non-distro builds. (It is also much faster than
> > using libbfd or bfd objdump on binaries with a lot of debug
> > information.)
> > 
> > This is nearly identical to the output of llvm-objdump; there are
> > some very rare whitespace differences, some minor changes to demangling
> > (since we use perf's regular demangling and not LLVM's own) and
> > the occasional case where llvm-objdump makes a different choice
> > when multiple symbols share the same address. It should work across
> > all of LLVM's supported architectures, although I've only tested 64-bit
> > x86, and finding the right triple from perf's idea of machine
> > architecture can sometimes be a bit tricky. Ideally, we should have
> > some way of finding the triplet just from the file itself.
> 
> <SNIP>
  
> > @@ -1730,6 +1918,11 @@ int symbol__disassemble(struct symbol *sym, struct annotate_args *args)
> >  		strcpy(symfs_filename, tmp);
> >  	}
> >  
> > +#ifdef HAVE_LIBLLVM_SUPPORT
> > +	err = symbol__disassemble_llvm(symfs_filename, sym, args);
> > +	if (err == 0)
> > +		goto out_remove_tmp;
> > +#endif
> >  #ifdef HAVE_LIBCAPSTONE_SUPPORT
> >  	err = symbol__disassemble_capstone(symfs_filename, sym, args);
> >  	if (err == 0)
> 
> So the above makes it unconditionally be used, and if the user installed
> llvm-devel, that now gets checked and suggested at build time, then that
> is an indication that it should be used, but I wonder if, for debugging
> purposes we shouldn't have this done in some configurable way, i.e. some
> ~/.perfconfig variable that allows us to try a specific disassembler,
> something like:
> 
> 	perf annotate --disassemble=capstone
> 
> I can even envision having some perf test that compares the output for
> some well known function to see if they really produce the same output
> from different disassemblers, etc.

Namhyung, do you see a problem with this?

- Arnaldo
 
> I'm applying the patches, thanks!