Debugging on the DM355/DM365?

I have used this on DM355 before; the following wiki may help

    http://tiexpressdsp.com/index.php/Debugging_remotely_on_DaVinci_using_gdb

If you prefer to use DDD graphical interface to GDB, see

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraap9

Thanks Juan, 

I see gdbserver in /usr/bin on the DM355. But gdbserver isn't in my file system on the DM365, so I'll have to take a stab at cross compiling it to the DM365.

DM365 software is still in its early stages; at present you can try cross compiling or better yet, using the DM355 version (both DM355 and DM365 have ARM9s).

I think DM365 EVM from TI intentionally removed gdb tools from Linux package !

I used a gdb from other Montavista distributions, it can only debug single thread program.

It does not work for multiple-thread program debugs for thread library reasons!

Maybe TI can tell how to work with multiple-thread debug

Tao_SV said:

I think DM365 EVM from TI intentionally removed gdb tools from Linux package !

This is true, the gdb tools were removed due to licensing concerns, however you can download and rebuild gdb to use it, we just cannot pre package it with the tool set, this actually applies to all MVL 5.0 releases on going. There is an article here that describes the process of rebuilding gdb and gdbserver, which than goes onto initiating the tools.

Tao_SV said:

Maybe TI can tell how to work with multiple-thread debug

I have not tried it myself, but I suspect that the multi thread debug capability of GDB is still there for the ARM, if you are having library issues than you may have to run "(gdb) set solib-search-path /home/user/workdir/filesys/lib" or similar for the path to your target filesystem. After doing this I can get a positive output from gdb with 'info threads':

GDB Output said:

(gdb) info threads
 1 Thread 862  0x400007e0 in _start ()
   from /home/user/workdir/filesys/lib/ld-linux.so.3
(gdb)

Are cmem.ko and dm350mmap.ko necessary for running gdb to debug program? I have tried to uninstall the two modules,and I find that the gdb can not connect to gdbserver.  

They should not be, thery are two drivers independant of gdb.  What version of DVSDK software are you using?

Hello,

TI Emplyee, my DVSDK version is 1.3.0

When I install the dm355mmap.ko and cmem.ko, the gdb can connect to gdbserver and work well

Hello

TI employee,

I have read the article in the following link:

http://tiexpressdsp.com/index.php/Debugging_remotely_on_DaVinci_using_gdb which you told me.

I find that the step "Now execute ./loadmodules.sh as always to insert necessary kernel modules" is necessary for debugging .

Thank you.

Let me try to clear things up a bit. 

1) gdb is an open source debugger which is independant of cmemk.ko or dm355mmap.ko; you do not need these two modules to debug say a hello.c word program. 

2) depending on which program you are trying to debug with gdb, then you will need to make sure that all the necessary support is in place for the program to run; if the program cannot run, then debugging will be difficult.  when you run loadmodules.sh, it loads cmemk.ko and dm355mmap.ko because these modules are necessary for the encode, decode or encodedecode demo to run.  If you cannot run these demos, then you will have a hard time doing any run-time debugging. 

Therefore, in summary, there is no dependancy between cmemk.ko or dm355mmap.ko with gdb; however, there is a dependancy between these .ko modules and the DVSDK demos.