Messages in this thread | | | From | David Mosberger <> | Date | Fri, 29 Mar 2002 09:08:01 -0800 | Subject | Re: [PATCH] generic show_stack facility |
| |
>>>>> On Fri, 29 Mar 2002 16:06:18 +0000, Christoph Hellwig <hch@infradead.org> said:
Christoph> On Fri, Mar 29, 2002 at 07:46:07AM -0800, David Mosberger Christoph> wrote: >> Christoph, why do you think the prototype for ia64 is different?
Christoph> I have stopped to wonder why ia64 does things Christoph> differently.
You might want to reconsider that stance. It could open your mind. ;-)
BTW: this is not at all an ia64-specific issue. It applies to any arch that doesn't maintain a frame pointer on the stack. Basic compiler technology.
>> It's because it *has to be*. In general, you can't do a >> backtrace without having the full (preserved) state of the CPU at >> the point of which the backtrace begins.
Christoph> So your suggestion is to move the other architectures to Christoph> the ia64 prototype or to not have an Christoph> architecture-independand stack-traceback facility at all?
I haven't done such an investigation. I believe the ia64 prototype is reasonable and probably implementable on all platforms that can unwind the stack in the first place, but before making a change to the stable kernel API, I'd think someone would have to investigate this a bit further.
One issue to consider is whether it's safe to call the routine on a task that is running on another processor. The ia64 implementation can handle this gracefully, because it's sometimes better to print a meaningless (garbled) stack trace than to make provably certain that the task won't be running on any other CPU. A related question is whether the routine can be called with interrupts masked.
My sense is this is something that should be considered for 2.5 first.
--david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |