Re: Fwd: some questions about kernel debugging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Sep 10, 2010 at 10:32 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi...

2010/9/10 loody <miloody@xxxxxxxxx>:
> Is it the limitation of kernel source debugging?
> ( cannot print out the value of variable)

Ehm..not sure, but one thing for sure: debugger can only see as much
information as the ones that exists inside the kernel image. In this
case: symbol table, a table that describe the relation between a
function or variable or anything and its location in memory (before
relocation, so it's more like an offset).


> I guess it maybe due to kernel image is impossible include frame information.
> (actually I don't quite well understand what is the frame used for,
> but from google, it seems the key point that gdb can watch the value
> of parameter)

Although I am not 100% sure here, you might try enable "Compile kernel
with debug info" inside kernel hacking menu during kernel
configuration (and quite possibly you need to recompile your kernel).
or...as alternative, if you use stock kernel from your distro, install
the kernel image from "debug info" repository.

It basically add -g to the gcc, thus embedding so called DWARF
information to the final kernel image. It would be a great help for
any debugger to locate the symbol in memory.

As for the "value optimized out", quite likely it's "erased" since
compiler thinks it's not actually used. Why compiler do this (when we
use -O1 or O2 etc)? Simple, to conserve space and speed up execution.
So if you still see -O<something> in your CFLAGS inside the main
Makefile, you may also try to delete it. 
-g and -O are not a good combination.

Removing -O flag in the kernel makefile doesn't work. the kernel refuses to boot if the optimization flag is disabled for kernel compilation. Till now, nobody has been able to answer this correctly in this mailing list.
Specifically, how do we disable all compiler optimizations so that GDB doesn't go nuts while debugging the kernel. Please let us know if anybody knows a solution to the problem here. 
 

NB: Frame pointer? Generally it's a "variable" (actually it's
processor register) reserved to record the stack boundary during
function call. perhaps you recall that when we call a function, we
push the passed parameters into stack? along with the current
instruction pointer (current address of executed instruction)? frame
pointer mark this boundary.

What's the difference? Enabling this...and you'll get better stack
tracing (also known as back tracing). it's a procedure to trace which
function calls which function and where exactly it's called.

Does it clear your doubts?

--
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux