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: [PATCH] Set default to -fomit-frame-pointer


On 11/08/2017 11:16 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
> 
>> I'd actually prefer to deprecate the H8 and M68k.  But assuming that's
>> not going to happen in the immediate future I think dropping frame
>> pointers on those targets is appropriate as long as we're generating
>> dwarf frame info.
> 
> Is there a way to check a target does not generate dwarf? I thought that
> was the default.
Hmm, looks like H8 is ELF only at this point and unconditionally turns
on dwarf2 debug records and has bits to enable dwarf2 CFI records.

I suspect -gstabs would likely turn all that off, but well, the more I
think about it, I don't care :-)


> 
>>> I believe in those cases targets already force the frame pointer as required,
>>> for example msp430 sets the frame pointer if unwind tables are emitted
>>> irrespectively of the command-line or default setting. Various other targets
>>> don't even use frame_pointer_needed and just do their own thing.
>> I've had the "pleasure" of going round and round on this repeatedly
>> through the years with the kernel teams on this.  Essentially they
>> didn't want to embed the dwarf2 unwinder in the kernel or have all those
>> pages of unwind data.  Instead they strongly preferred to have a frame
>> pointer to facilitate easy and fast unwinding.
> 
> A frame pointer does not facilitate unwinding, it can give a backtrace at best.
Sorry.  I was being imprecise in my choice of words.   A backtrace is
what the kernel guys need for various reasons.  In some cases the
backtrace is generated at interrupt time (handling of profiling events),
so it can't depend on the dwarf interpreter or the dwarf tables.

>> So  my concern is to make sure the kernel folks, particularly in the
>> ia32 world aren't going to get hosed by this change.  If we're changing
>> the default it needs to be signaled to them so that they can ensure that
>> if they want frame pointers that they still get them.
> 
> x86/x64 is not affected since it already omits the frame pointer by default (like
> almost all targets in a target specific way). This patch is about making that
> the global default precisely because pretty much every target already has it
> as the default.
Yea, I guess we fixed 32bit x86 eons ago.

So I think the final conclusion is to go with your change.  If there's
any fallout on h8 or m68k we'll deal with it.

Jeff


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