Messages in this thread | | | Date | Thu, 13 Mar 2014 15:03:41 -0700 | Subject | Re: [RFC] improve_stack: make stack dump output useful again | From | Linus Torvalds <> |
| |
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
| |