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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Aug 2014 10:32:23 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Namhyung Kim <namhyung.kim@....com>,
	LKML <linux-kernel@...r.kernel.org>, Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH 8/8] perf symbol: Don't demangle parameters and such by
 default

Em Mon, Aug 11, 2014 at 05:17:37PM +0900, Namhyung Kim escreveu:
> On Sat, 2 Aug 2014 10:35:03 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jul 31, 2014 at 02:47:42PM +0900, Namhyung Kim escreveu:
> >> Some C++ symbols have very long name and they make column length
> >> longer.  Most of them are about parameters including templates and we
> >> can ignore such info most of time IMHO.

> >> This patch passes DMGL_NO_OPTS by default when calling bfd_demangle().
> >> One can still see full symbols with -v/--verbose option.

> >> before:
> >>   JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*)

> >> after:
> >>   JS_CallFunctionValue

> > Are you sure we want that?

> > With this we'll end up having different instantiations having the same
> > name, since the way to differentiate them is exactly by a different
> > parameter list, no?
> 
> Right, but I think it's not a big problem since such overloaded
> functions will not be shown at the same time as only one of them might
> do the real work most cases.  Simply noticing one of them is a

But then only someone that has deep knowledge of the code in question
will figure that out from just the function name.

A way to toggle that, starting with a sane value, in this case probably
not showing the parameter listing due to it being overly long would be
ideal.

Perhaps I can process this patch now and leave this toggling of things
that --verbose shows to a second patchset, where this and
--show-total-period, --show-nr-samples, --hide-unresolved, even
annotation stuff needs to be on-the-fly togglable, like
--disassembly-style.

> performance bottle neck would be helpful to the developer, I guess.
> Even if it's not the case, one still can see and identify the correct
> one using the -v option.
 
> For me, it's just annoying when (unimportant) C++ symbols occupy too
> much space in a limited terminal width.

What is annoying/unimportant to a person may be the missing detail for
someone else.

Not having to restart a possibly long top/report session from scratch
looks like a nice feature to have.

I'll take the patch, its just one more thing that gets in the --verbose
grab bag till we make all on-the-fly togglable.
 
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists