lkml.org 
[lkml]   [2014]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] improve_stack: make stack dump output useful again
From
On Thu, Mar 13, 2014 at 8:16 AM, Sasha Levin <sasha.levin@oracle.com> 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 don't care about build performance compile with debug
info, and even if you do do that, the kernel won't load it anyway.

You missed the point.

The kernel is going to *remove* all the hex numbers that your script
relies on, because those hex numbers are completely worthless. They
are worthless and annoying now, but they are *doubly* worthless if the
kernel is compiled with base address randomization, since nobody will
know what the hex numbers mean.

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

You're missing something big. The patch I sent earlier *is* going to
happen one of these days, possible for 3.15. So your script that looks
at hex numbers is broken.

You need to look at the *symbol* number. In this output:

[<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0

that "ffffffff810020c2" is crap, and is going away. The address that
is meaningful and valid is the "do_one_initcall+0xc2" part.

*That* is the part you'd use to parse in user space.

Try it today with the CONFIG_RANDOMIZE_BASE option to see. Using the
hex number doesn't *work*.

Linus


\
 
 \ /
  Last update: 2014-03-13 23:41    [W:0.161 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site