linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
Date: Tue, 05 May 2009 19:11:20 -0400	[thread overview]
Message-ID: <1241565080.11379.14.camel@localhost.localdomain> (raw)
In-Reply-To: <299D7402-29D3-4602-8F42-58FDF034DEC5@kernel.crashing.org>


On Tue, 2009-05-05 at 15:51 +0200, Segher Boessenkool wrote:
> >>> When we add "-pg" to gcc, it automatically causes frame pointers  
> >>> to be
> >>> used.
> >>
> >> Nope, it does no such thing.
> >
> > Well, mcount is expected to be able to get to not just who called
> > mcount, but also the parent of that function. The way mcount is
> > implemented does not let you do that. If mcount was the first thing to
> > be called in a function, then it would have been perfect. We could get
> > to the caller, its parent, and even the parameters. But unfortunately,
> > mcount is called after the stack is set up. Thus, without frame  
> > pointers
> > (the way to find a previous frame) there's no way (on some archs) to
> > find the parent. Nor can we figure out the parameters, which really
> > sucks.
> 
> Yes, and this is (supposedly) why GCC does not like seeing -pg and
> -fomit-frame-pointer at the same time -- because that cannot work
> *on some architectures*.  These are the same architectures that
> do not enable -fomit-frame-pointer automatically at -O.
> 
> >> NO_NO_OMIT_FRAME_POINTER ?  Or better, just never use -fno-o-f-p,
> >> I don't see why you would ever need it.
> >
> > Because on x86_64 it gives better back traces. x86_64 has no way to  
> > get
> > to the previous frames without it. There's code to use other debug
> > metadata to get back tracing, but for uses of things like the stack
> > tracer, we need to be able to use the actual stack frames.
> >
> > As you said above, -fomit-frame-pointer is default when we  
> > optimize, and
> > that is how the kernel is built. If we optimize on x86_64 and do  
> > not use
> > -fno-omit-frame-pointer, the stack tracer is useless.
> 
> No.  -fomit-frame-pointer is only the default when optimising on
> archs/ABIs where it doesn't hinder debugging and -pg and all that
> goodness; specifically, you do not get it by default on x86, not
> at any optimisation level.


OK, so what's the status with this patch series?

I don't want to pull it in unless I have an ack from Sam, and now
there's issues with having -fno-omit-frame-pointer. Should we add a
patch instead that simply removes that?

If we eliminate the -fno-omit-frame-pointer, would that solve the PPC
problem? And would it cause any other issues with other archs?

-- Steve

  reply	other threads:[~2009-05-05 23:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-02  0:13 [PATCH v5 0/3] Tracers vs. CALLER_ADDR on PowerPC Anton Vorontsov
2009-05-02  0:14 ` [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER Anton Vorontsov
2009-05-02 19:48   ` Segher Boessenkool
2009-05-03  2:04     ` Steven Rostedt
2009-05-05  7:56       ` Segher Boessenkool
2009-05-05 13:33         ` Steven Rostedt
2009-05-05 13:51           ` Segher Boessenkool
2009-05-05 23:11             ` Steven Rostedt [this message]
2009-05-18  4:14               ` Benjamin Herrenschmidt
2009-05-18 19:55                 ` Segher Boessenkool
2009-05-02  0:14 ` [PATCH 2/3] powerpc: Remove -fno-omit-frame-pointer workarounds Anton Vorontsov
2009-05-02  0:14 ` [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER Anton Vorontsov
  -- strict thread matches above, loose matches on Subject: below --
2009-03-20 16:44 [PATCH v4 0/3] Tracers vs. CALLER_ADDR on PowerPC Anton Vorontsov
2009-03-20 16:44 ` [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER Anton Vorontsov
2009-03-21  3:49   ` Steven Rostedt
2009-03-28 10:48     ` Anton Vorontsov
2009-03-29 22:54       ` Benjamin Herrenschmidt
2009-03-30  4:36         ` Sam Ravnborg
2009-04-05 21:07   ` Sam Ravnborg
2009-04-13 15:51     ` Steven Rostedt
2009-05-02  0:14     ` Anton Vorontsov

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=1241565080.11379.14.camel@localhost.localdomain \
    --to=srostedt@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=sam@ravnborg.org \
    --cc=segher@kernel.crashing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).