Execution of gdbserver on dm6467t fails

Gerard,

Can you set the following on your gdbserver session and see if that helps:

(gdb) set solib-absolute-prefix <path_to_filesystem>
(gdb) set solib-search-path <path_to_filesystem>/usr/lib;<path_to_filesystem>/lib

For e.g.

(gdb) set solib-absolute-prefix /toolchains/DA850/DaVinci-PSP-SDK-03.20.00.01/images/fs/nfs
(gdb) set solib-search-path /toolchains/DA850/DaVinci-PSP-SDK-03.20.00.01/images/fs/nfs/usr/lib;/toolchains/DA850/DaVinci-PSP-SDK-03.20.00.01/images/fs/nfs/lib/

Deepali

Hi Deepali,

Thanks for the answer. But I can't try it because i've figured out that youre advice assumes the gdbserver session

is available. But what happens is that I can't open a session at all. The problem seems to be that it doesn't find

the library libthread_db.so.1 in the filesystem.

I've been looking around, and I've found the following:  in the demo filesystem, appears  the library libpthread-2.8.so which is accessed via a soft link through the

file libpthread.so.0.  But there's no libthread_db.so.1. I looked in both versions of filesystem: in the one supplied with the EVM board, and the one available on the net,

which is the current one.

I've been looking for relations between gdbserver and the kernel source. I've made a search over the dvsdk root directory looking for strings like 'gdb' or 'gdbserver'. I've found that there's a place within xdc tools where appears a java application with a name related to gdbserver: in the path

xdctools_3_16_01_27/packages/gnu/gdb/jserver/package

you can find files like:

gnu_gdb_jserver.java or gnu_gdb_jserver.class.

To tighten the relation between gdbserver and kernel libraries, I've done a search through the Makefile provided with the dvsdk. What I found is that in some point of the Makefile collection, the xcd tools are used to build the dsplink kernel module.

That gave me two ideas to try:

1- Run .loadmodules to load the dsplink before running the gdbserver.

2- Boot the system with the kernel compiled with the same version of source of that of the filesystem.

Neither worked.

Everything points to the following:  some important component within the installation is missed, but I've double-checked it and seems that it's ok.

It terminantly seems that the libthread_db.so.1 is not available in the demo version. Is that true?

At last, the following action worked:

I've created the followign simlink:

root@dm6467t-evm:/lib# ln -s libpthread-2.8.so libthread_db.so.1
root@dm6467t-evm:/lib# gdbserver
Usage:  gdbserver COMM PROG [ARGS ...]
        gdbserver COMM --attach PID

COMM may either be a tty device (for serial debugging), or
HOST:PORT to listen for a TCP connection.

What resumes the whole mess in a misnaming issue.

Thanks for your attention. I hope this will help others!

Gerard,

Thanks for your detailed analysis. I assumed gdbserver is up.

I will point this post to the concerned DVSDK folks to get to the root cause of the misnaming issue.

Deepali

Gerard,

I spoke to TI DVSDK engineers regarding the misnaming issue. This issue will be fixed in the upcoming release. This is what they have to say:

Those are different libraries (libpthread and libthread_db) and the second one is really missing. Symlinking one to another seemed to let customer run gdbserver, but once he starts debugging multi-threaded apps, it will fail.

Here is the IPK with the library, which was missing:

http://arago-project.org/files/releases/2009.11/ipk/armv5te/libthread-db1_2.8-r1.3_armv5te.ipk

Get it to the board and run “opkg install libthread-db1_2.8-r1.3_armv5te.ipk”

Deepali

Hi Deepali,

While waiting for your response, I tried an alternative:  I've copied the libraries (all the lib/ directory) supplied with CodeSourcery, in the version 

pointed by the "GSG: DVEVM Software Setup  for DM6467 platforms" instructions (the http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain link).

to the root filesystem (so, replacing the originals) on the board (1). I checked out that the lib/ version matched the one reported by the "arm-none-linux-gnueabi-gcc --print-multi-directory" command as can be

read in the CodeSourcery Getting started guide (http://www.codesourcery.com/sgpp/lite/arm/portal/doc4337/getting-started.pdf), sections 3.1.1 and 3.1.2.

I've copied also the CodeSourcery version of gdbserver executable.

When I fired the gdbserver, it  worked as expected, waiting for a connection. But when in the host I pointed to the remote target, what could be seen was this:

On the gdbserver side:

root@dm6467t-evm:/opt/dvsdk/WingsForMedia/proves# gdbserver 192.168.0.2:50000 prova
Process prova created; pid = 1612
Listening on port 50000
Remote debugging from host 192.168.0.1
gdbserver: relocation error: gdbserver: symbol td_ta_new, version GLIBC_2.4 not defined in file libthread_db.so.1 with link time reference
Compatdor= 0
Compatdor= 1
Compatdor= 2
Compatdor= 3
Compatdor= 4
Compatdor= 5
Compatdor= 6
Compatdor= 7
Compatdor= 8
Compatdor= 9
root@dm6467t-evm:/opt/dvsdk/WingsForMedia/proves#

And on the client arm-none-linux-gnueabi-gdb side, on the host:

gguerrero@wfmdevstationU:~/workdir/filesys/opt/dvsdk/WingsForMedia/proves$ arm-none-linux-gnueabi-gdb prova
GNU gdb (Sourcery G++ Lite 2009q1-203) 6.8.50.20081022-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>...
(gdb) target remote 192.168.0.2:50000
Remote debugging using 192.168.0.2:50000
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x400007b0 in ?? ()
Remote connection closed
(gdb)

So, the moves I made let me execute the program remotely, but I couldn't debug it.

The questions:

- Is this error the one pointed by your TI DVSDK colleagues?

- To apply what you suggested me in the last mail, should I replace the whole filesystem with the arago-demo-version again, to start from scratch, or can I give a try to the CodeSourcery bins an libs?

I've been browsing a little, and I've found that the CodeSourcery versions for libthread_db date from 2009-05-21 (this is the date reported in the files present in the downloaded tar), and the one you point me is newer (11-Dec-2009), so I think using CodeSourcery's bins and libs with the version you suggest could fail. Am I right?

Thank you in advance, again!

(1) In fact, it's not the filesystem resident on the board. It is an nfs mounted filesystem, but I refer it that way for simplicity.

Hi Deepali,

I have the same problem when I try to run gdbserver on Zoom OMAP L138 eXperimenter Kit.

gdbserver: error while loading shared libraries: libthread_db.so.1: cannot open shared object file: No such file or directory

Do I run the same command to install the missing shared object ?

rgds,

kc Wong

Ok. I have found the libthread_db.so.1 in one of the Sourcery_G++_Lite installation directories.

./Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/libthread_db.so.1
./Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/armv4t/lib/libthread_db.so.1
./Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/thumb2/lib/libthread_db.so.1

I just copy the first one into the /lib of the target file system and run gdbserver. Everything works fine now.

I had a similar issue that I am sharing here assuming it could be helpful to others. I use the OMAP-L138 based ZOOM board.

Remote debugging was working fine for a single threaded program. However, multi threaded program debugging was not working properly. There wasn't any error/warning as others have cited on gdbserver. But the gdb 'info threads' command was listing only one, the main thread, though there were multiple threads. Also I was unable to stop the code by setting breakpoint at a place in the sourcecode which is run by a different thread.

To isolate the problem I cross-compiled gdb for the target board and ran gdb directly on the target board to debug the multi-threaded program.  Then I got the following error and it was still showing only one thread.

(gdb) run
Starting program: /home/manhattan_lc
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
(gdb) info threads
  Id   Target Id         Frame
* 1    LWP 980 "manhattan_lc" main (argc=1, argv=0xbea92da4)
    at ./src/um_main.c:102

I found that libthread_db was already there in the /lib directory of the target. Then I thought it may be either due to version mismatching with the libpthread library or the symobol stripping problem as the library was stripped (Reference: http://sourceware.org/gdb/wiki/FAQ).
So I copied both the libpthread and libthread_db libraries from CodeSourcery directory to the target. Then the multi threaded program debugging worked fine.