Re: [GIT PULL] x86/kaslr for v3.14

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, Jan 28, 2014 at 11:48 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> I really meant it when I said I build without debuginfo! :)

Ok, but so what?

As mentioned, nobody sane should build with DEBUG_INFO. But a normal
vmlinux file has the symbol information even without it.

> So, when I build a kernel, such as with a regular 'make defconfig',
> the following happens in gdb:
>
>   Reading symbols from /home/mingo/tip/vmlinux...(no debugging symbols found)...done.
>   (gdb) list schedule+0x45
>   No symbol table is loaded.  Use the "file" command.
>
> Is there a way to resolve schedule+0x45 in a regular vmlinux? It was
> an honest question.

That seems to be just a gdb bug (or "UI feature"), in that gdb likes
to give misleading error messages and requires odd syntax for some
things.

The symbols are there (see the first line):

  Reading symbols from /home/mingo/tip/vmlinux...(no debugging symbols
found)...done.

and that "no debugging symbols found" is just because you don't have
the extra *debug* info.

The "list" command requires debug info to work (since that's where the
line number information is), and will not work with hex symbols either
if you don't have that. So when it says "No symbol table is loaded" it
really means "no debug information is loaded".

But you can see that the symbol is perfectly fine:

  (gdb) list *(schedule+0x45)
  No symbol table is loaded.  Use the "file" command.
  (gdb) x/3i schedule+0x45
     0xffffffff81616d05 <schedule+69>: adc    0x1(%rsi),%bh
     0xffffffff81616d0b <schedule+75>: callq  0xffffffff812c0b30
<blk_flush_plug_list>
     0xffffffff81616d10 <schedule+80>: jmp    0xffffffff81616cdf <schedule+31>

(ok, so 0x45 wasn't the start of a real instruction, but you get the idea).

So my point is that the hex address doesn't give you *anything* that
the symbolic address doesn't give you. Unless you do truly crazy
things like actively strip the kernel.

              Linus