CCS V5.1 Not able to check variables for Linux Kernel Debugging at all.

Hi,

Over the years and using different Linux kernel versions, one thing I noticed is that the optimization applied to the several modules plays a huge part in the visibility of variables and the ability to single step throughout the code - even with complete debug symbols used. The reason is that the optimizer may group variables into registers, inline functions, change the order of the code execution and so on.

Therefore, one suggestion is to remove the optimization in specific files (something that will require hacking the kernel build process) or apply breakpoints in specific points or in the modules you created (instead of performing long single stepping sequences).You can always remove optimization entirely, but this would be a lot more intrusive in the normal operation of your system.

Unfortunately I can't think of any additional that could help in this case, but maybe someone from the community may chime in with additional ideas. 

Using Windows or Linux versions of CCS do not influence in this behaviour.

Hope this helps,

Rafael

Hi Tianhua,

This is not normal.

Asm code should match the source code.

Global variables should be available.

Are you sure the target is running the same kernel image as your kernel symbol (vmlinux ) ?

What target are you using ?

What is the version of Linux Kernel ?

-Raymond

But Linux kernel has to be built with optimizations. I don't see if there is a way to turn it off.

Thanks,

Yes vmlinux is always the same with the kernel image.

My target is OMAP3530.

Linux kernel is 3.0.

Thanks,

Hi Tian:   make sure you are using the same uImage that was created when you built the Linux kernel with debugging to boot your board. If not, then the instruction streams won't necessarily correspond and you get weird behaviour. Depending on how you normally boot your board, the new uImage must always be deployed, along with any corresponding modules onto the root.

For instance, during [early] dev, I usually boot via TFTP with the root on NFS. To reduce possibility of errors or glitches, I created a quick script that subsumes the kernel build, and at the end, deploys the SPL/uBoot, uImage to /tftproot and vmlinuz, modules to the NFS share being mounted as the root file system.

As a safeguard to mixing modules in the same version of kernel from different builds, use the Linux kernel configuration's "Local version suffix" to distinguish [at least] between free build and debug build.

Cheers

Thanks for your reply.

Yes I am using the same uImage with vmlinux.

The ASM code alone looks not messed up. I.e., if I step down in the ASM window, I don't see any misplaced instructions. But the source code debugging including step over/step in does not seem to work unless this is only an assignment code line. And I believe when I single step in the source code file, it is actually single stepping in the ASM instructions thus it takes more steps to pass one source code line, during which the cursor inside the C source code lines jumps back and forth between irrelavant code lines.

And from the "variables" watch window, usually it will show auto variables defined and used inside a function. But now I am seeing sometime it gives me  several auto variables, most of them cannot be seen or evaluated without any reason. And from "Expression" window, almost none of the expressions e.g. gloabal variables etc will not show me anything but "unknown".

Well the registers look trustable everytime.