Hi Paulo,

Paulo Marques wrote:
quoted text
> 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).


quoted text
>>> 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
--
unsubscribe notice
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/