Remote debugging on DM6467T using gdbserver Fails

Not sure, but might be related to this:

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

Chris

Dear Chris,

 Thank you for your reply.

I tried the steps provided in the link above, but did not help. GDB is still not able to catch any signal after Engine_open().

i also tried couple of more things,

a) Modified /dvsdk_3_10_00_12/codec_engine_2_25_01_06//packages/ti/sdo/ce/ipc/dsplink/Processor_dsplink_linkcfg_OS.c (disabled signal handling), rebuilt IPC/dsplink and application

b) Modified /dvsdk_3_10_00_12/dsplink_linux_1_64/dsplink/config/all/CFG_Linux.c (disabled signal handling), rebuilt dsplink and application

But none of the above step yielded any good result.

Regards,

Prashanth

Prashanth,

I dont think step b will work for you. It has be step a detailed in the wiki link sent earlier.

Which specific signals are you interested in? Is it the list in CFG_Linux.c or others as well? DSPLink will register a signal handler only for that list.

DSPLink registers a default signal handler. It does seem to me that this is still not getting disabled. To confirm can you a put a print in function DSPLINK_sigHandler in file  $(DSPLINK)/gpp/src/api/Linux/drv_api.c, do a rebuild of DSPLink and application and see if it is still getting printed when gdb catches the signal. It should not be getting printed.

Deepali

Deepali,

Thank you for your response.

Basically i am trying to debug my Codec Engine based Application using GDB server on DM6467T with DVSDK 3.10.00.12. And I noticed that my application and GDB hangs whenever i put a breakpoint or introduce segmentation fault (say divide by 0) after Engine_Open() call. If i do the same before Engine_Open() it works fine, ie i am able to put breakpoints and work with GDB.

i am not sure whether the problem is due to signal handler in DSPLINK. Because i think the signal handler in DSPLINK gets executed only when the process is about to terminate, which is not the case in my situation (even breakpoints are not working).

Also, since the file system which came along with DVSDK did not contain 'gdbserver' and 'libthread_db.so', i did following steps to get gdb on my platform. Could you please let me know whether these steps are correct or if i am missing out something.

1) Got libthread_db.so from the following post:  (http://e2e.ti.com/support/embedded/f/354/t/47210.aspx)

2) Downloaded and built 'termcap' library
Downloaded from: ftp://ftp.gnu.org/gnu/termcap/termcap-1.3.1.tar.gz

Built using following commands, 

export PATH=<toolchain-path>:$PATH

export CC=<cross-compiler-name>

export AR=<cross-archiver-name>

export RANLIB=<cross-ranlib-name>

./configure --build="i686-pc-linux-gnu" --host="arm-none-linux-gnueabi" --target="arm-none-linux-gnueabi"
make

Copied termcap.h to toolchain include directory (/opt/dm6467/toolchain/arm-2009q1/arm-none-linux-gnueabi/include/c++/4.3.3/ directory), and libtermcap.a to toolchain lib directory (/opt/dm6467/toolchain/arm-2009q1/arm-none-linux-gnueabi/libc/usr/lib/)

2) Downloaded and built 'ncurses' library

Downloaded from: http://linux.softpedia.com/get/Programming/Libraries/Ncurses-6097.shtml

Built using following commands, 

export PATH=<toolchain-path>:$PATH

export CC=<cross-compiler-name>

export AR=<cross-archiver-name>

export RANLIB=<cross-ranlib-name>

./configure --build="i686-pc-linux-gnu" --host="arm-none-linux-gnueabi" --target="arm-none-linux-gnueabi"
make

Copied ncurses library to toolchain lib directory (/opt/dm6467/toolchain/arm-2009q1/arm-none-linux-gnueabi/libc/usr/lib/)

3) Downlaod and built gdb v6.8

Downloaded from: http://ftp.gnu.org/gnu/gdb/

Built using following commands,

export PATH=<toolchain-path>:$PATH

export CC=<cross-compiler-name>

export AR=<cross-archiver-name>

export RANLIB=<cross-ranlib-name>

./configure --build="i686-pc-linux-gnu" --host="arm-none-linux-gnueabi" --target="arm-none-linux-gnueabi" --disable-tui
make

Copied 'gdbserver' to my target file system 'usr/bin'

Prashanth

Prashanth,

The hang on CTRl C could still be because of the signal handler but Breakpoints not working after Engine_open is a strange issue,

I have debugged DSPLink using gdb using the standard known PSP and file system and it has worked with no issues. I have not tried CTRL C. Also, my file system already had the gdbserver and thread utilities.

Let me pull in a few more experts on this one.

Deepali

Prashanth,

I cannot comment on debugging DSPLINK, but wanted to comment on the whole GDB and compiling from sources topic...

Normally, GDB is not very picky and you can mix and match different versions of gdb and gdbserver. But, unfortunately, if you need to debug multi-threaded apps, there are some dependencies for specific APIs...

For example, this is one of the messages you may see if you didn't build GDB properly for the thread support:

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.

Due to the GPLv3 licensing, we can only provide built versions of GDB and gdbserver up to version 6.6, which is slightly old now.

The good news is that CodeSourcery comes with its own versions of GDB and gdbserver version 6.8 - you can find them here:

/opt/arm-2009q1/bin/arm-none-linux-gnueabi-gdb
/opt/arm-2009q1/arm-none-linux-gnueabi/libc/usr/bin/gdbserver

You can also look at http://elinux.org/GDB for general debugging tips and some Angstrom specifics, which should also be applicable for Arago.

Denys,

Thank you for your response.

Just wanted to clear that the problem appears even with a single threaded simple Codec Engine based application. Not sure if Engine_Open() creates a new thread.

Also, i tried using the '/opt/arm-2009q1/arm-none-linux-gnueabi/libc/usr/bin/gdbserver', but got the same problem.

Is there anything special which Engine_Open() does in DVSDK 3.10.00.12 for DM6467T? Since the problem does not appear for other platforms wich we are working on.

Regards,

Prashanth

Nothing special for DM6467T - same ol' Engine_open().  It does [as always] create a pthread if there are remote algorithms - which is likely for DM6467T.

Are there any obvious differences between platforms that work and those that don't (e.g. Link versions?)?

Chris

Chris,

One major difference which i noticed is that, on all the platforms on which GDB is working we are using Montavista based kernel. But on DM6467T we are using GIT kernel v2.6.32. Could this cause any problem?

Prashanth

Prashanth,

Which GDB are you using with MontaVista based systems? Did you build it yourself or did it come with the system?

Denys,

We are using GDB which came along with the filesystem.