Re: [PATCH] m68knommu: add pretty back strace

[Greg Ungerer]

Hi Paulo,

Paulo Marques wrote:
> Sebastian Siewior wrote:
> > * Paulo Marques | 2008-05-02 20:27:57 [+0100]:
> >
> > > Greg Ungerer wrote:
> > > > From: Sebastian Siewior <bigeasy@xxxxxxxxxxxxx>
> > > > 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@xxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/