Linux CCsv5.1 M6 Variables window has wrong data...

Hm, since it's showing some of the locations in Registers, I'm guessing there is at least some optimization turned on -- even though you've turned it off.  The libraries you link to might not have been compiled in full debug O0.

If the code is not fully UNoptimized, then the individual load/compute/store stages of the pipeline are very hard to track down, and it's amazing CCS can do anything at all (though very often inaccruate). If you're still in the debugging stage, then printf() is probably your best bet for finding out what values are at certain points.

It doesn't just show some of the locations in registers...it pretty much looks like all the variables seem to be based off of R11 only (ARM cpu).  And there is no way to set this. Apparently, the debugger thinks (sic) it knows whatever calling convention and register convention the toolchain uses, even though there doesn't seem to be a mechanism for the user to set this...must be a pretty smart debugger...;)...Is there a built-in TI compiler in CCS?  If so, maybe this is the convention it uses?

This is Linux kernel code, and as far as I know there aren't any libraries linked in, most externals are resolved by a dynamic kernel loader.  Even it there was a library the code I'm referring to are my own functions, not some calls to kernel or other libraries.  The toolchain in use is GCC (whatever version TI recommended for 8148EVM ezsdk).  I can surmise the registers in use via the disassembly window (aahhh...all that time learning assembler is actually good for something...;)...and their not R11.

I've specifically disabled all optimization (-O0), but I'm not that familiar with the GCC tool chain on ARM.  That is to say, even if you tell GCC to not optimize there may be specific things it does that it must do regardless of what you tell it (i.e. like datatype alignment optimizations, etc.,...).  Also, it could be that the Linux kernel headers turn it on somewhere and maybe don't turn it back off.  I would think that the debug information generated by the compiler would/should contain information about variables/locals...other tool chains do...but again, I'm not that familiar with the GCC tool chain...I don't know the answer to these questions....;(...

Bottom line is that the way it currently is implemented is useless for Linux kernel debugging.  The variables window doesn't display the correct information. And trying to do anything else to see data structures, etc.,...is a real time killer from a productivity perspective.

CCS comes with at least one version of the compiler for various platforms (selectable/deselectable at installation), and other versions can be added -- but that doesn't seem to be your concern.

Other than -O0 and -g, I'm not aware of any other debugging flags.  If you are using a Debug configuration, than likely -g is already enabled as "Full symbolic debug".

I guess I never really asked what the extent of "wrong information" in the variable window meant -- does that mean that the contents of the variables are wrong or that it's showing the set of variables from a different function?

If it's the different set of variables, then that's likely a result of inlined functions and some other compiler messiness.

If it's the contents, then is it ACTUALLY getting wrong values? Like 2+2=5, or are you referring to that uninitialized variables are present in the window but have some pseudo-random value until they become initialized.  As I mentioned earlier, if it's not doing 100% explicit debug stepping (which you might not be able to control, but I typically haven't had problems if it's code that you yourself wrote and not linked in from some library), then there could exist some configuration of intermediate calculations that uses the register where a variable is being stored.

And if you are bringing in source code from somewhere such as needing to do "locate file" or utilizing the "Source Path Lookup" while debugging (again, not a problem if all the code is self-contained), then make 100% sure you've chosen the right file for the right version.  Different versions will more than likely have the same or similar variables, but the lines of code may be different, thus giving different values at different points.

Sorry for your trouble so far, but I'd be glad to help as much as I can.

These links might also be relevant

http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5#Stop_Mode_Debug

http://processors.wiki.ti.com/index.php/How_to_Run_GDB_on_CCSv5

I've already built the Linux kernel with debug info in it, and I load the symbols to it prior to adding the symbols for my kernel module.

To be clear, the code I'm debugging isn't being built with the CCS compiler.  Instead, it's being built using the Linux Kernel build system as an "out-of-tree" module.  The GCC options for debug are enabled (-g -O0), so whatever debug/symbol info this compiler generates is being added to the generated objects.  The linker is also not tossing the debug info, it's putting it into the final .ko module.  When I load the module into the debugger (via add symbols) and eventually arrive at my breakpoint I get proper source code for Linux kernel and/or my kernel module (depending upon where it actually breaks).  I set up the source paths in the debug configuration.  I'm not using any "project" definition, only a target config and a debug config.  Appears that you don't really need a "project" to do this level of debugging.

When I initially wrote this post (about M6 release) I didn't have the "OS Aware" module loaded.  Not sure why you folks enable this by default on Windows but not on Linux??? (see this post http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/114904.aspx).  Not sure if this would effect the variables pane or not???

Not only are the contents of the variables window wrong (even after I've executed the C function prologue), but if I attempt to "set" any variable it sets the variable at whatever address the debugger thinks the variable is, which isn't the correct address, frequently resulting in undefined behaviour (it's defined alright...it usually culminates in a trap sooner or later...;)...

Hi Joe,

What version of the Linux Kernel are you debugging ?

What version of the GCC compiler are using ?

Recently, we discover that there are problems in resolving variable locations for kernels built with GCC 4.5.

GCC 4.5 emits newer version of debug information that CCS does not support.

Regards,

Raymond

GCC --version says

       gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

The Linux kernel is linux-2.6.37-psp04.01.00.02

The compiler is recommended by TI as part of their ezsdk for the new Centaurus line, specifically the DM8148 ezsdk. This is the version of Linux they've distributed in the ezsdk. 

We had an issue ourselves with the compiler.  My co-worker told me that this GCC is some intermediary version of the compiler.  He had a problem with some of the include files when he was trying to build something...the standard build includes didn't have an underscore for some variables, but this one did.  He indicated he queried CodeSourcery web site and they indicated it was an intermediary build and they fixed this problem in the next release...apparently, they've removed it from their site.

When you compile your psp kernel, you are not using your host gcc.

You are using a cross-compiled ARM gcc toolchain from CodeSourcery.

If you are using CodeSourcery ARM tool chain version 2009-q1, then the problem I mention above does not apply to your case.

Do you rebuild the Linux kernel from the PSP kit  OR just use the kernel from the PSP kit ?

What is the value of the PC when you observe the wrong variable values ?

and

What are the variable names ?

Regards,

Raymond

Sorry Ray...I was looking at the wrong place for the compiler...I forgot to setup my work environment...we've got an internal build group that integrates all vendor packages into "our" build system...I didn't have the correct environment when I ran GCC...as you so asutely noticed...TGIF...it's been a long week...;)...

The "real" compiler used is the ARM cross compiler...it's listed as:

   arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3

I rebuilt the kernel from the PSP kit, but tweaked it a bit to add debug info and a few other things.

I load my module with insmod on the 8148EVM target under linux (I don't need to debug the startup).  I've got a small script I used to use for gdb debugging that generates an "add-symbol-file" gdb command script, so I run this to get the addresses of where the module was loaded.  The code section appears to always get loaded at 0xbf000000.  I've noticed that the CCS "Add Symbols" dialog now not only has the "Code offset", but it now has a "Data offset" too...M5 didn't have this as I recall.  Anyway, I'm not sure what section needs to be set here because it looks like there's a number of sections in my module that contain data, but I set it to the section call ".data", which at the moment is at address 0xbf0167c4.  I then set a breakpoint in my code at a function entry point (on opening curly brace), tell CCS to resume, and then run a small test program on the target that causes the breakpoint to be hit.  I get all my source correct displayed.  I then do a "Step Into" to run the function prologue, which lands me on a couple of locals I've got defined at the top of the function, one of which does an assignment.  The line looks like this:

     size_t    i, retc = 0;

The value of PC is 0xbf0053a4 (before it initializes retc=0).  If I again "Step Into" I do not see retc set to zero in the variables window.  It still has the same value as before the step (3347283724), it does not change.  The variables window shows the "Location" as register R11 for both i and retc.  The disassembly show that retc is indeed based off of R11, but it looks like it offset by -16 from R11. R11 is pointing at 0xc7837f0c after the step that sets retc to 0. The disassembly up to this point looks like this:

1286      {
          InitCamera:
bf005394:   E1A0C00D MOV             R12, R13
bf005398:   E92DD800 STMFD           R13!, {R11, R12, R14, PC}
bf00539c:   E24CB004 SUB             R11, R12, #4
bf0053a0:   E24DD010 SUB             R13, R13, #16
1287          size_t      i, retc = 0;
bf0053a4:   E3A03000 MOV             R3, #0
bf0053a8:   E50B3010 STR             R3, [R11, #--16]
1291          for (i = 0; i < INIT_RETRY_TIMEOUT; i++)

A register dump looks like this:

Core Registers   
    PC    0xBF0053AC    Core Register: Program Counter   
    SP    0xC7837EF0    Core Register: General Purpose Register 13   
    LR    0xBF005510    Core Register: General Purpose Register 14   
    CPSR    0x60000013    Core Register: Stores the status of interrupt enables and critical processor status signals   
    R0    0xC7043610    Core Register: General Purpose Register 0   
    R1    0x000054E4    Core Register: General Purpose Register 1   
    R2    0xBF0172E4    Core Register: General Purpose Register 2   
    R3    0x00000000    Core Register: General Purpose Register 3   
    R4    0xC7122080    Core Register: General Purpose Register 4   
    R5    0xC0508320    Core Register: General Purpose Register 5   
    R6    0xC0508380    Core Register: General Purpose Register 6   
    R7    0xC7800EC0    Core Register: General Purpose Register 7   
    R8    0xC7043000    Core Register: General Purpose Register 8   
    R9    0xBF002350    Core Register: General Purpose Register 9   
    R10    0x00000000    Core Register: General Purpose Register 10   
    R11    0xC7837F0C    Core Register: General Purpose Register 11   
    R12    0xC7837F10    Core Register: General Purpose Register 12   
    R13    0xC7837EF0    Core Register: General Purpose Register 13   
    R14    0xBF005510    Core Register: General Purpose Register 14   

Hope this helps.

To debug Linux Kernel module, you cannot simply use Add-Symbol to load the kernel symbol.

If you manage to figure where each section is relocated, you may be able to use a GEL script to relocate each section.

It probably is easier if you enable Linux OS debug and let CCS relocate the symbol for you.

-Raymond

Ok...well...not sure why...I've been using this method to debug LKM with not issues other than the variables window issues noted here.  All source code debugging appears to get relocated properly once I put correct code section address into the Add-Symbol dialog.  Like I said, the M6 build added an additional "Data" address, but you didn't reply to my question as to which data section was supposed to go there.  I guess from my description it appears I must be doing what you folks term "Stop Mode Debug"?

At any rate, I don't have a problem is enabling Linux OS debug.  Actually, I already have done that and it didn't seem to make any difference, but I concede I may not be doing something correctly.

I think part of the issue is that there doesn't appear to be clear directions for how to do this using a current Linux Kernel and CCSv5.  All info in this regard is documented for CCSv4, and while admittedly, the dialogs in CCS are the same, a number of other issues may not be. 

For instance, the link http://processors.wiki.ti.com/index.php/Linux_Aware_Debug describes this feature in detail, but the instructions about Module Debug in regards to patching the kernel appear outdated to me due to kernel changes since this has been written.  When I looked into this some weeks back I couldn't determine where or what I was supposed to modify with what code I was supposed to use for the modifications.  I don't have intimate details of how you folks are doing your debugging or what you do or how you examine the Linux Kernel when you're in a stopped state.

Again, for the non-modified kernel directions, the directions are described in a form that is relative to the modified kernel (i.e. "Whenever halted in the module load/unload routines' and then breakpoints must then be manually set on the same lines of code that would have been modified to call TI_CCS_Notify_Module_List_Changed() if the kernel were patched.")...if the modified kernel directions need to be updated then it looks like the non-modified directions also need this, no?

At any rate, it's not clear to me how I can get "Linux OS debug" beyond enabling it in the CCSv5 interface, which I've already done...I am currently unsure what is required beyond this, and apparently cannot use any variable debug dialogs until other things are done.  Either way I'm at an impasse in this regard.

Suggestions?