Re: [PATCH] m68knommu: add pretty back strace

Greg Ungerer
2008-05-06T04:52:37Z

Hi Paulo,

Paulo Marques wrote:
> Sebastian Siewior wrote:
>> * Paulo Marques | 2008-05-02 20:27:57 [+0100]:
>>
>>> Greg Ungerer wrote:
>>>> From: Sebastian Siewior <bigeasy@linutronix.de>
>>>> With this patch and
>>>> CONFIG_FRAME_POINTER=y
>>>> CONFIG_KALLSYMS=y
>>>> The backtrace shows resolved function names and their numeric
>>>> address.
>>> This is really not my area, but this patch reminds me of all the
>>> dwarf2 unwinder on x86 that caused so many problems in the beginning...
>>>
>>>> [...]
>>>> +#ifdef CONFIG_FRAME_POINTER
>>>> + printk(KERN_EMERG "Call Trace:\n");
>>>> +
>>>> + last_stack = stack - 1;
>>>> + while (stack <= endstack && stack > last_stack) {
>>>> +
>>>> + addr = *(stack + 1);
>>>> + printk(KERN_EMERG " [%08lx] ", addr);
>>>> + print_symbol(KERN_CONT "%s\n", addr);
>>>> +
>>>> + last_stack = stack;
>>>> + stack = (unsigned long *)*stack;
>>>> }
>>>> printk("\n");
>>>> +#else
>>>> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic
>>>> call trace\n");
>>> You could probably fall back to the old method in this case, no?
>> The old method printed every value from stack which was in the text
>> range (you didn't get modules AFAIK). This might be the caller as well a
>> function pointer as argument as well something else. I tried to find to
>> find a pattern without frame pointers but I had no luck. I thing the
>> caller fixed the stack frame or something.
>> Greg did not complain about removing it. If you or others want the old
>> method in case of no frame pointers I can send a patch.
>
> Having output garbled with "false positive" addresses, but that have the
> "true positives" in between is better than no output at all.

Yes that is a reasonable argument.

But you still get the full stack hex dump, so all the raw information
is there still. Just not in a decoded form. (I tended to use the raw
dump more often myself anyway).

>>> Also, if the stack is slightly corrupted on the top, the new method
>>> might just bail out without giving any indication about the path that
>>> lead there, when instead it could also fall back to the old method.
>> You mean by slightly that the first caller ORed the address with
>> something?
>
> Or more commonly, a buffer overflow... (or underflow, depending on how
> the stack grows)
>
>> In that case we don't return safely. I don't know how I could
>> find out the right time for a fallback (in case of slightly corrupted
>> stack).
>
> I was imagining you would get a page fault where you'd show a stack
> trace, but that's on a MMU processor. With no MMU I guess you don't get
> a chance to do that :(
>
> As I said before, this is really not my area. I just remember that a
> very similar change in x86 was a real pain, and wanted to make sure that
> everyone here was aware of that.

I would have no problem with the original full symbolic decode
being in as a fall back for the non FRAME_POINTER case.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com