All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <srostedt@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Paul Mackerras <paulus@samba.org>,
	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: 40+ 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:13 ` 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  0:14   ` Anton Vorontsov
2009-05-02 19:48   ` Segher Boessenkool
2009-05-02 19:48     ` Segher Boessenkool
2009-05-03  2:04     ` Steven Rostedt
2009-05-03  2:04       ` Steven Rostedt
2009-05-05  7:56       ` Segher Boessenkool
2009-05-05  7:56         ` Segher Boessenkool
2009-05-05 13:33         ` Steven Rostedt
2009-05-05 13:33           ` Steven Rostedt
2009-05-05 13:51           ` Segher Boessenkool
2009-05-05 13:51             ` Segher Boessenkool
2009-05-05 23:11             ` Steven Rostedt [this message]
2009-05-05 23:11               ` Steven Rostedt
2009-05-18  4:14               ` Benjamin Herrenschmidt
2009-05-18  4:14                 ` Benjamin Herrenschmidt
2009-05-18 19:55                 ` Segher Boessenkool
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   ` Anton Vorontsov
2009-05-02  0:14 ` [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER Anton Vorontsov
2009-05-02  0:14   ` 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-20 16:44   ` Anton Vorontsov
2009-03-21  3:49   ` Steven Rostedt
2009-03-21  3:49     ` Steven Rostedt
2009-03-28 10:48     ` Anton Vorontsov
2009-03-28 10:48       ` Anton Vorontsov
2009-03-29 22:54       ` Benjamin Herrenschmidt
2009-03-29 22:54         ` Benjamin Herrenschmidt
2009-03-30  4:36         ` Sam Ravnborg
2009-03-30  4:36           ` Sam Ravnborg
2009-04-05 21:07   ` Sam Ravnborg
2009-04-05 21:07     ` Sam Ravnborg
2009-04-13 15:51     ` Steven Rostedt
2009-04-13 15:51       ` Steven Rostedt
2009-05-02  0:14     ` Anton Vorontsov
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 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.