All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Martin Liška" <mliska@suse.cz>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	David Ahern <dsahern@gmail.com>, Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC] The -Og debugging experience
Date: Mon, 7 Dec 2015 15:04:27 +0100	[thread overview]
Message-ID: <566591EB.5080404@suse.cz> (raw)
In-Reply-To: <20151207134542.GB26191@krava.brq.redhat.com>

On 12/07/2015 02:45 PM, Jiri Olsa wrote:
> On Mon, Dec 07, 2015 at 11:48:07AM +0100, Martin Liška wrote:
>> On 12/02/2015 05:48 PM, Jiri Olsa wrote:
>>> heya,
>>> using the -Og for DEBUG=1 builds gives me many 'optimized out' stuff
>>>
>>> It was introduced in here:
>>>   e8b7ea4356fd perf tools: Improve setting of gcc debug option
>>>
>>> - here's backtrace from segfault I was looking at, current code:
>>
>> Hi.
>>
>> Can you please provide a test-case which I can use for testing of the issue?
> 
> just run perf report in gdb and kill it with sigsegv from other terminal
> this gives me several instances of <optimized out> right in the backtrace
> 
> jirka
> 

Hi.

Unfortunately, running 'perf report' for a medium-size report is very fast a
killing the process from other terminal produces:

[Current thread is 1 (Thread 0x7ffff7fc5740 (LWP 7429))]
(gdb) bt
#0  0x00007ffff632d230 in __write_nocancel () from /lib64/libc.so.6
#1  0x00007ffff62c4dff in _IO_new_file_write () from /lib64/libc.so.6
#2  0x00007ffff62c4403 in new_do_write () from /lib64/libc.so.6
#3  0x00007ffff62c5d09 in __GI__IO_do_write () from /lib64/libc.so.6
#4  0x00007ffff62c5417 in __GI__IO_file_xsputn () from /lib64/libc.so.6
#5  0x00007ffff6299cdb in vfprintf () from /lib64/libc.so.6
#6  0x00007ffff62a03f7 in fprintf () from /lib64/libc.so.6
#7  0x00000000004ef12c in hist_entry__fprintf (he=he@entry=0x1c62b30, size=<optimized out>, size@entry=0, hists=hists@entry=0x1813818, 
    bf=bf@entry=0x1d5cd40 "     0.08%  cc1plus   cc1plus", ' ' <repeats 11 times>, "[.] _Z25number_of_iterations_exitP4loopP8edge_defP15tree_niter_descbb", ' ' <repeats 91 times>..., bfsz=bfsz@entry=479, fp=fp@entry=0x7ffff65f0640 <_IO_2_1_stdout_>)
    at ui/stdio/hist.c:427
#8  0x00000000004ef549 in hists__fprintf (hists=hists@entry=0x1813818, show_header=show_header@entry=true, max_rows=max_rows@entry=0, max_cols=max_cols@entry=0, min_pcnt=0, fp=0x7ffff65f0640 <_IO_2_1_stdout_>) at ui/stdio/hist.c:534
#9  0x000000000042d6a3 in perf_evlist__tty_browse_hists (evlist=0x1812c90, rep=rep@entry=0x7fffffffc6e0, help=help@entry=0x515948 "For a higher level overview, try: perf report --sort comm,dso") at builtin-report.c:370
#10 0x000000000042d7d2 in report__browse_hists (rep=rep@entry=0x7fffffffc6e0) at builtin-report.c:455
#11 0x000000000042d992 in __cmd_report (rep=rep@entry=0x7fffffffc6e0) at builtin-report.c:571
#12 0x000000000042ec1f in cmd_report (argc=0, argv=0x7fffffffde00, prefix=<optimized out>) at builtin-report.c:957
#13 0x000000000046c496 in run_builtin (p=p@entry=0x7771a0 <commands+192>, argc=argc@entry=1, argv=argv@entry=0x7fffffffde00) at perf.c:387
#14 0x000000000046c693 in handle_internal_command (argc=1, argv=0x7fffffffde00) at perf.c:448
#15 0x000000000046c6fe in run_argv (argcp=argcp@entry=0x7fffffffdc6c, argv=argv@entry=0x7fffffffdc60) at perf.c:492
#16 0x000000000046c94c in main (argc=1, argv=0x7fffffffde00) at perf.c:609

Which is fine.

I've been using GCC 5.2. What version are you using?
I've also tried to run './perf test' and terminate the process at random places, but the back trace was OK.

I would appreciate if you send me a patch that causes a segfault that is wrongly displayed.
Thanks,
Martin

  reply	other threads:[~2015-12-07 14:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 16:48 [RFC] The -Og debugging experience Jiri Olsa
2015-12-03  8:29 ` Ingo Molnar
2015-12-07 10:48 ` Martin Liška
2015-12-07 13:45   ` Jiri Olsa
2015-12-07 14:04     ` Martin Liška [this message]
2015-12-07 14:16       ` Jiri Olsa
2015-12-10 13:07         ` Martin Liška
2015-12-10 13:24           ` Jiri Olsa
2015-12-10 15:13             ` Arnaldo Carvalho de Melo
2015-12-11  9:17               ` Martin Liška
2015-12-14  8:15 ` [tip:perf/core] Revert "perf tools: Improve setting of gcc debug option" tip-bot for Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566591EB.5080404@suse.cz \
    --to=mliska@suse.cz \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.