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. > > 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. But indeed, frame pointers, unwinding and stack chains are often confused despite being completely orthogonal concepts... > 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. Wilco