On Fri, Mar 14, 2014 at 12:41 PM, Linus Torvalds
wrote:
> On Fri, Mar 14, 2014 at 12:32 PM, Linus Torvalds
> wrote:
>>
>> Hmm. Do you have CONFIG_KALLSYMS enabled?
>
> Just to clarify. KALLSYMS is required to figure out the symbol
> addresses on a kaslr system. There's no way to look them up in a
On Fri, Mar 14, 2014 at 12:32:23PM -0700, Linus Torvalds wrote:
> On Fri, Mar 14, 2014 at 12:08 PM, Dave Jones wrote:
> >
> > ok, nokalsr makes it work too.
> > Booting with that and using the perf binary from 3.14rc6 , I just see..
> >
> > 9.30% [kernel] [k] 0xff
On Fri, Mar 14, 2014 at 12:32 PM, Linus Torvalds
wrote:
>
> Hmm. Do you have CONFIG_KALLSYMS enabled?
Just to clarify. KALLSYMS is required to figure out the symbol
addresses on a kaslr system. There's no way to look them up in a
System.map file or the object file, since the addresses aren't goin
On Fri, Mar 14, 2014 at 12:08 PM, Dave Jones wrote:
>
> ok, nokalsr makes it work too.
> Booting with that and using the perf binary from 3.14rc6 , I just see..
>
> 9.30% [kernel] [k] 0xaf18e887
Hmm. Do you have CONFIG_KALLSYMS enabled?
I have CONFIG_RANDOMIZE_BAS
On Fri, Mar 14, 2014 at 12:08 PM, Dave Jones wrote:
> On Fri, Mar 14, 2014 at 11:31:11AM -0700, Kees Cook wrote:
> > On Thu, Mar 13, 2014 at 4:12 PM, Dave Jones wrote:
> > > On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
> > >
> > > > You need to look at the *symbol* number.
On Fri, Mar 14, 2014 at 11:31:11AM -0700, Kees Cook wrote:
> On Thu, Mar 13, 2014 at 4:12 PM, Dave Jones wrote:
> > On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
> >
> > > You need to look at the *symbol* number. In this output:
> > >
> > > [] do_one_initcall+0xc2/0
On Fri, Mar 14, 2014 at 11:31:11AM -0700, Kees Cook wrote:
> On Thu, Mar 13, 2014 at 4:12 PM, Dave Jones wrote:
> > On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
> >
> > > You need to look at the *symbol* number. In this output:
> > >
> > > [] do_one_initcall+0xc2/0
On Thu, Mar 13, 2014 at 4:12 PM, Dave Jones wrote:
> On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
>
> > You need to look at the *symbol* number. In this output:
> >
> > [] do_one_initcall+0xc2/0x1e0
> >
> > that "810020c2" is crap, and is going away. The addres
On Thu, Mar 13, 2014 at 4:07 PM, Sasha Levin wrote:
>
> I figured that I'll just read it from System.map (and do the math when
> adding the offset). That should work, right?
Yes, although just reading the symbols from the vmlinux file would be
*much* more convenient, since I know that not everybo
On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
> You need to look at the *symbol* number. In this output:
>
> [] do_one_initcall+0xc2/0x1e0
>
> that "810020c2" is crap, and is going away. The address that
> is meaningful and valid is the "do_one_initcall+0xc2"
On 03/13/2014 06:59 PM, Linus Torvalds wrote:
On Thu, Mar 13, 2014 at 3:20 PM, Sasha Levin wrote:
I'll fix it up and re-send this patch.
The problem (as you will find out) is that "addr2line" doesn't take
symbolic names.
So either addr2line needs to be improved (which really would be a good
On Thu, Mar 13, 2014 at 3:20 PM, Sasha Levin wrote:
>
> I'll fix it up and re-send this patch.
The problem (as you will find out) is that "addr2line" doesn't take
symbolic names.
So either addr2line needs to be improved (which really would be a good
idea regardless), or your script needs to use
On 03/13/2014 06:03 PM, Linus Torvalds wrote:
On Thu, Mar 13, 2014 at 8:16 AM, Sasha Levin wrote:
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.
No no no. The *kernel* will never do line
On Thu, Mar 13, 2014 at 8:16 AM, Sasha Levin wrote:
>
> 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.
No no no. The *kernel* will never do line numbers, especially since
only people who d
On 02/23/2014 03:27 PM, Linus Torvalds wrote:
On Sat, Feb 22, 2014 at 4:19 PM, Sasha Levin 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] [] ? backtrace_test_irq_callback+0x20/0x20
[6.9071
On Sun, Feb 23, 2014 at 12:44 PM, Joe Perches wrote:
>
> I'd rather see this as a vsprintf extension so
> that it is more difficult to interleave and
> doesn't need to be replicated for each arch.
We could easily get rid of printk_[stack_]address() by just inlining
it into the callers, and make t
On Sun, 2014-02-23 at 12:27 -0800, Linus Torvalds wrote:
> 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 d9
On Sat, Feb 22, 2014 at 4:19 PM, Sasha Levin 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] [] ? backtrace_test_irq_callback+0x20/0x20
> [6.907121] [] dump_stack+0x52/0x7f
> [6.90
Right now when people try to report issues in the kernel they send stack
dumps to eachother, which looks something like this:
[6.906437] [] ? backtrace_test_irq_callback+0x20/0x20
[6.907121] [] dump_stack+0x52/0x7f
[6.907640] [] backtrace_regression_test+0x38/0x110
[6.908281] [
19 matches
Mail list logo
