All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sasha.levin@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] improve_stack: make stack dump output useful again
Date: Thu, 13 Mar 2014 11:16:42 -0400	[thread overview]
Message-ID: <5321CBDA.1060705@oracle.com> (raw)
In-Reply-To: <CA+55aFxPL9dWAK-y0tDFj5r6ikKytqnxL3A+9KH55GpmCQFf9Q@mail.gmail.com>

On 02/23/2014 03:27 PM, Linus Torvalds wrote:
> On Sat, Feb 22, 2014 at 4:19 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
>> Right now when people try to report issues in the kernel they send stack
>> dumps to eachother, which looks something like this:
>>
>> [    6.906437]  [<ffffffff811f0e90>] ? backtrace_test_irq_callback+0x20/0x20
>> [    6.907121]  [<ffffffff84388ce8>] dump_stack+0x52/0x7f
>> [    6.907640]  [<ffffffff811f0ec8>] backtrace_regression_test+0x38/0x110
>> [    6.908281]  [<ffffffff813596a0>] ? proc_create_data+0xa0/0xd0
>> [    6.908870]  [<ffffffff870a8040>] ? proc_modules_init+0x22/0x22
>> [    6.909480]  [<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0
>> [...]
>>
>> However, most of the text you get is pure garbage.
>
> I'd like to fix that, but I'd like to fix it in the kernel, and just
> stop printing the hex addresses entirely.
>
> However, your kind of script actually makes that worse, in that it
> uses the redundant hex addresses for 'addr2line', and that tool is
> known to not work with symbolic addresses, only with actual numerical
> ones.
>
> So I would *really* want to do this kernel change (possibly
> conditional on RANDOMIZE_BASE_ADDRESS or whatever the config variable
> is called):
>
>      diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
>      index d9c12d3022a7..58039e728f00 100644
>      --- a/arch/x86/kernel/dumpstack.c
>      +++ b/arch/x86/kernel/dumpstack.c
>      @@ -27,13 +27,12 @@ static int die_counter;
>
>       static void printk_stack_address(unsigned long address, int reliable)
>       {
>      -       pr_cont(" [<%p>] %s%pB\n",
>      -               (void *)address, reliable ? "" : "? ", (void *)address);
>      +       pr_cont(" %s[<%pB>]\n", reliable ? "" : "? ", (void *)address);
>       }
>
>       void printk_address(unsigned long address)
>       {
>      -       pr_cont(" [<%p>] %pS\n", (void *)address, (void *)address);
>      +       pr_cont(" [<%pS>]\n", (void *)address);
>       }
>
>       #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
> which would make the kernel stack traces much prettier.
>
> But that would require that there be a "resolve symbolic address" (if
> CONFIG_KALLSYMS isn't enabled, it would still be hexadecimal) for the
> address inside the [<>] thing..
>
> I don't know of any sane tool that does that directly, but it
> shouldn't be *that* hard. You can *almost* do it with
>
>    echo "p backtrace_regression_test+0x38" | gdb vmlinux
>
> but you see the problem if you try that ;)

I've looked into doing it in the kernel, but it seems that it would require a rather
large code addition just to deal with getting pretty line numbers.

Unless I'm missing something big, is it really worth it?


Thanks,
Sasha


  parent reply	other threads:[~2014-03-13 15:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-23  0:19 [RFC] improve_stack: make stack dump output useful again Sasha Levin
2014-02-23 20:27 ` Linus Torvalds
2014-02-23 20:44   ` Joe Perches
2014-02-23 20:55     ` Linus Torvalds
2014-03-13 15:16   ` Sasha Levin [this message]
2014-03-13 22:03     ` Linus Torvalds
2014-03-13 22:20       ` Sasha Levin
2014-03-13 22:59         ` Linus Torvalds
2014-03-13 23:07           ` Sasha Levin
2014-03-14  0:50             ` Linus Torvalds
2014-03-13 23:12       ` Dave Jones
2014-03-14 18:31         ` Kees Cook
2014-03-14 18:33           ` Dave Jones
2014-03-14 19:08           ` Dave Jones
2014-03-14 19:31             ` Kees Cook
2014-03-14 19:32             ` Linus Torvalds
2014-03-14 19:41               ` Linus Torvalds
2014-03-14 20:15                 ` Kees Cook
2014-03-14 20:08               ` Dave Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5321CBDA.1060705@oracle.com \
    --to=sasha.levin@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.