This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers

From: Jeff Law <law at redhat dot com>
To: Andrew Pinski <pinskia at gmail dot com>
Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, dnovillo at google dot com, gcc-patches at gcc dot gnu dot org
Date: Wed, 27 Feb 2013 14:48:47 -0700
Subject: Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
References: <ye6qhakx7bxl.fsf@elbrus2.mtv.corp.google.com> <CA+=Sn1mwqqbWfdGqk7MH_YYhgUxiv=LySmeqHHLco7RrKg7Xpw@mail.gmail.com> <CALoOobPBHBDtkeFbOuTSf+NCEAyD6=9p+OKEXKc9VTJ-LdZTZw@mail.gmail.com> <512E7244.7010100@redhat.com> <CA+=Sn1=XiQWMAG7brH4krLnW-E0UJeTLQ9C9FHgi=LMqE2J-bA@mail.gmail.com>

On 02/27/2013 02:46 PM, Andrew Pinski wrote:

Perf handles this by saving off some of the stack space instead and
then post-process it.  This is why I said perf handles this case
already.  Now oprofile does not but oprofile is really going away.

I'm well aware of how perf handles this, having had numerous discussions with Red Hat's kernel team about this issue.

jeff

References:
- [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
  - From: Paul Pluzhnikov
- Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
  - From: Andrew Pinski
- Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
  - From: Paul Pluzhnikov
- Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
  - From: Jeff Law
- Re: [google gcc-4_7, integration] Build more of libstdc++ with frame pointers
  - From: Andrew Pinski

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]