(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Allow building the x86-64 kernels with frame pointers if so needed.
Signed-off-by: Jan Beulich <[email protected]>
diff -Npru 2.6.13/lib/Kconfig.debug
2.6.13-x86_64-frame-pointer/lib/Kconfig.debug
--- 2.6.13/lib/Kconfig.debug 2005-08-29 01:41:01.000000000 +0200
+++ 2.6.13-x86_64-frame-pointer/lib/Kconfig.debug 2005-09-02
09:57:40.000000000 +0200
@@ -151,7 +151,7 @@ config DEBUG_FS
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
- depends on DEBUG_KERNEL && ((X86 && !X86_64) || CRIS || M68K ||
M68KNOMMU || FRV || UML)
+ depends on DEBUG_KERNEL && (X86 || CRIS || M68K || M68KNOMMU ||
FRV || UML)
default y if DEBUG_INFO && UML
help
If you say Y here the resulting kernel image will be slightly
larger
On Thursday 08 September 2005 18:04, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Allow building the x86-64 kernels with frame pointers if so needed.
This doesn't work because you would need to pass -fno-omit-frame-pointer
somewhere. Also I don't see much sense because all the assembly code
will break the frame chains.
-Andi
>>> Andi Kleen <[email protected]> 09.09.05 10:54:11 >>>
>On Thursday 08 September 2005 18:04, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> Allow building the x86-64 kernels with frame pointers if so needed.
>
>This doesn't work because you would need to pass
-fno-omit-frame-pointer
>somewhere.
So is done in the top-level makefile.
>Also I don't see much sense because all the assembly code
>will break the frame chains.
Sure, but that's a different issue.
Jan
On Friday 09 September 2005 11:16, Jan Beulich wrote:
> >>> Andi Kleen <[email protected]> 09.09.05 10:54:11 >>>
> >
> >On Thursday 08 September 2005 18:04, Jan Beulich wrote:
> >> (Note: Patch also attached because the inline version is certain to
>
> get
>
> >> line wrapped.)
> >>
> >> Allow building the x86-64 kernels with frame pointers if so needed.
> >
> >This doesn't work because you would need to pass
>
> -fno-omit-frame-pointer
>
> >somewhere.
>
> So is done in the top-level makefile.
Indeed. Someone must have fixed it. But why would anyone want frame pointers
on x86-64?
-Andi
> But why would anyone want frame pointers on x86-64?
I'd put the question differently: Why should x86-64 not allow what
other architectures do?
But of course, I'm not insisting on this patch to get in, it just
seemed an obvious inconsistency...
Jan
On Fri, 9 Sep 2005, Jan Beulich wrote:
> > But why would anyone want frame pointers on x86-64?
>
> I'd put the question differently: Why should x86-64 not allow what
> other architectures do?
>
> But of course, I'm not insisting on this patch to get in, it just
> seemed an obvious inconsistency...
I'm with Jan on this. I use a similar patch for frame pointers on
x86_64 most of the time, in the hope of getting more accurate backtraces.
Is x86_64 somehow more likely to give you a less noisy backtrace than
i386? Fewer of those stale return addresses from earlier trips down
the stack?
Frame pointers are imperfect on all(?) the supported architectures,
but I can't see any good reason to exclude them from x86_64. Just a
couple of weeks ago LKML had a bug where enabling frame pointers on
x86_64 helped Ingo to pinpoint the origin of the problem.
Hugh
On Friday 09 September 2005 12:45, Hugh Dickins wrote:
> On Fri, 9 Sep 2005, Jan Beulich wrote:
> > > But why would anyone want frame pointers on x86-64?
> >
> > I'd put the question differently: Why should x86-64 not allow what
> > other architectures do?
> >
> > But of course, I'm not insisting on this patch to get in, it just
> > seemed an obvious inconsistency...
>
> I'm with Jan on this. I use a similar patch for frame pointers on
> x86_64 most of the time, in the hope of getting more accurate backtraces.
It won't give more accurate backtraces, not even on i386 because show_stack
doesn't have any code to follow frame pointers.
> Is x86_64 somehow more likely to give you a less noisy backtrace than
> i386? Fewer of those stale return addresses from earlier trips down
> the stack?
I have a plan to fix this - basically Jan's NLKD has
code to read the unwind information and then do an accurate backtrace
without frame pointers. The plan is to port that code over
(it currently requires too much infrastructure from the debugger
and needs some coding style fixes) and then add something like
CONFIG_RUNTIME_UNWIND_INFO that puts the unwind information into
the running kernel. Then you'll get accurate backtraces without
frame pointers.
The NLKD code would work on i386 too so it could be later enabled
there then too.
IA64 works similar already BTW but the code is not really usable
for other architectures.
> Frame pointers are imperfect on all(?) the supported architectures,
> but I can't see any good reason to exclude them from x86_64. Just a
> couple of weeks ago LKML had a bug where enabling frame pointers on
> x86_64 helped Ingo to pinpoint the origin of the problem.
They are useless because the core kernel doesn't have any code
to follow them. That's true on i386 and on x86-64.
The only reason to use them would be external debuggers, but those
don't need them on x86-64 neither.
-Andi
On Fri, 09 Sep 2005 at 11:23 +0000, Andi Kleen wrote:
> Indeed. Someone must have fixed it. But why would anyone want frame pointers
> on x86-64?
Oprofile can use it, I though it was already used but apparently only
to backtrace userspace actually.
--
Philippe Elie
On Fri, 9 Sep 2005, Andi Kleen wrote:
>
> It won't give more accurate backtraces, not even on i386 because show_stack
> doesn't have any code to follow frame pointers.
Ah, right. I'm using kdb with it. (And my recollection of when
show_stack did have a framepointer version, is that it was hopelessly
broken on interrupt frames, and we're much better off without it.)
> The only reason to use them would be external debuggers, but those
> don't need them on x86-64 neither.
Don't need them, but find them as useful on x86_64 as on i386?
Certainly, I can go on patching in FRAME_POINTERs for x86_64
as I have done, no problem with that. But it seems both bogus
and unhelpful to have that "&& !X86_64" in lib/Kconfig.debug -
framepointers are as helpful/useless on x86_64 as the rest.
Hugh
On Fri, Sep 09, 2005 at 01:07:02PM +0200, Philippe Elie wrote:
> On Fri, 09 Sep 2005 at 11:23 +0000, Andi Kleen wrote:
>
>
> > Indeed. Someone must have fixed it. But why would anyone want frame pointers
> > on x86-64?
>
> Oprofile can use it, I though it was already used but apparently only
> to backtrace userspace actually.
You should be using dwarf2 unwind information instead. Near all
user space on x86-64 has it, and kernels sometimes too.
-Andi
On Fri, Sep 09, 2005 at 12:14:38PM +0100, Hugh Dickins wrote:
>
> Ah, right. I'm using kdb with it. (And my recollection of when
> show_stack did have a framepointer version, is that it was hopelessly
> broken on interrupt frames, and we're much better off without it.)
Not sure if the x86-64 kdb had code to follow them either.
The i386 one has.
>
> > The only reason to use them would be external debuggers, but those
> > don't need them on x86-64 neither.
>
> Don't need them, but find them as useful on x86_64 as on i386?
>
> Certainly, I can go on patching in FRAME_POINTERs for x86_64
> as I have done, no problem with that. But it seems both bogus
> and unhelpful to have that "&& !X86_64" in lib/Kconfig.debug -
> framepointers are as helpful/useless on x86_64 as the rest.
The original reason was that they were never enabled because
nobody passed -fno-omit-frame-pointer. That was apparently
later fixed.
But kdb should be using a dwarf2 unwinder instead. kgdb certainly
supports that, as does NLKD.
-Andi
On Fri, 9 Sep 2005, Andi Kleen wrote:
> On Fri, Sep 09, 2005 at 12:14:38PM +0100, Hugh Dickins wrote:
> >
> > Ah, right. I'm using kdb with it. (And my recollection of when
> > show_stack did have a framepointer version, is that it was hopelessly
> > broken on interrupt frames, and we're much better off without it.)
>
> Not sure if the x86-64 kdb had code to follow them either.
> The i386 one has.
x86_64 kdb does have the code to follow them, it's pretty much the same.
(kdb does have a bug in its x86_64 setjmp with framepointers, but that's
irrelevant to whether the x86_64 kernel supports framepointers.)
> But kdb should be using a dwarf2 unwinder instead. kgdb certainly
> supports that, as does NLKD.
In an ideal and bloat-neutral world. I've always imagined it to be
quite a lot of work, bringing in its own set of problems: but great
that that work has now been done, and yes, it might one day get
ported to kdb. But removing "&& !X86_64" is much easier.
Hugh
On Friday 09 September 2005 13:31, Hugh Dickins wrote:
> On Fri, 9 Sep 2005, Andi Kleen wrote:
> > On Fri, Sep 09, 2005 at 12:14:38PM +0100, Hugh Dickins wrote:
> > > Ah, right. I'm using kdb with it. (And my recollection of when
> > > show_stack did have a framepointer version, is that it was hopelessly
> > > broken on interrupt frames, and we're much better off without it.)
> >
> > Not sure if the x86-64 kdb had code to follow them either.
> > The i386 one has.
>
> x86_64 kdb does have the code to follow them, it's pretty much the same.
It will not work very well because the interrupt/exception etc. code makes
no attempt to preserve the frame. So it's a bad hack at best.
> > But kdb should be using a dwarf2 unwinder instead. kgdb certainly
> > supports that, as does NLKD.
>
> In an ideal and bloat-neutral world. I've always imagined it to be
> quite a lot of work, bringing in its own set of problems: but great
> that that work has now been done, and yes, it might one day get
> ported to kdb. But removing "&& !X86_64" is much easier.
Hmm ok. I will do that change.
-Andi
On Fri, 9 Sep 2005, Andi Kleen wrote:
> On Friday 09 September 2005 13:31, Hugh Dickins wrote:
> > On Fri, 9 Sep 2005, Andi Kleen wrote:
> > > But kdb should be using a dwarf2 unwinder instead. kgdb certainly
> > > supports that, as does NLKD.
> >
> > In an ideal and bloat-neutral world. I've always imagined it to be
> > quite a lot of work, bringing in its own set of problems: but great
> > that that work has now been done, and yes, it might one day get
> > ported to kdb. But removing "&& !X86_64" is much easier.
>
> Hmm ok. I will do that change.
Thanks, Andi.
Hugh
Philippe Elie a ?crit :
> On Fri, 09 Sep 2005 at 11:23 +0000, Andi Kleen wrote:
>
>
>
>>Indeed. Someone must have fixed it. But why would anyone want frame pointers
>>on x86-64?
>
>
> Oprofile can use it, I though it was already used but apparently only
> to backtrace userspace actually.
>
Hi Pilippe
Last time I tried oprofile with call graph on my opteron machine (linux-2.6.13
SMP), the machine crashed instantly in dump_backtrace()
Apparently the user program was in a state were 'struct frame_head * head' was
not part of the user thread stack, but some strange value like
0x8000000000xxyyzz
Eric
On Fri, Sep 09, 2005 at 12:58:12PM +0200 Andi Kleen wrote:
> On Friday 09 September 2005 12:45, Hugh Dickins wrote:
> > On Fri, 9 Sep 2005, Jan Beulich wrote:
> > > > But why would anyone want frame pointers on x86-64?
> > >
> > > I'd put the question differently: Why should x86-64 not allow what
> > > other architectures do?
> > >
> > > But of course, I'm not insisting on this patch to get in, it just
> > > seemed an obvious inconsistency...
> >
> > I'm with Jan on this. I use a similar patch for frame pointers on
> > x86_64 most of the time, in the hope of getting more accurate backtraces.
>
> It won't give more accurate backtraces, not even on i386 because show_stack
> doesn't have any code to follow frame pointers.
>
Huh? print_context_stack follows frame pointers which is called from
show_stack
Alexander Nyberg <[email protected]> wrote:
>
> On Fri, Sep 09, 2005 at 12:58:12PM +0200 Andi Kleen wrote:
>
> > On Friday 09 September 2005 12:45, Hugh Dickins wrote:
> > > On Fri, 9 Sep 2005, Jan Beulich wrote:
> > > > > But why would anyone want frame pointers on x86-64?
> > > >
> > > > I'd put the question differently: Why should x86-64 not allow what
> > > > other architectures do?
> > > >
> > > > But of course, I'm not insisting on this patch to get in, it just
> > > > seemed an obvious inconsistency...
> > >
> > > I'm with Jan on this. I use a similar patch for frame pointers on
> > > x86_64 most of the time, in the hope of getting more accurate backtraces.
> >
> > It won't give more accurate backtraces, not even on i386 because show_stack
> > doesn't have any code to follow frame pointers.
> >
>
> Huh? print_context_stack follows frame pointers which is called from
> show_stack
show_trace() uses print_context_stack(), but show_stack() just does a
dump-everything. I wondered why the CONFIG_FRAME_POINTER oops traces were
still so crappy. TIA ;)
On Saturday 10 September 2005 07:13, Andrew Morton wrote:
> show_trace() uses print_context_stack(), but show_stack() just does a
> dump-everything. I wondered why the CONFIG_FRAME_POINTER oops traces were
> still so crappy. TIA ;)
It's a good thing - it wouldn't have any chance to get beyond the exception
frame.
-Andi