• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 390 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320DM8148: The glibc dynamic library does not have a symbol table, so it is impossible to debug segmentation errors and bus errors

Annie Liu
Genius 10295 points
Part Number: TMS320DM8148

Hi Team,

The customer is experiencing below issue and needs your help.

Customer used dm8148. The rdk package is ipnc_3.8. However, the related dynamic libraries in the cross-compilation chain in the package and the lib libraries in the folder of the file system in the package all have no symbol table.  It is impossible to debug segmentation errors and bus errors. He downloaded, compiled and transplanted the 2.12.1 version of glibc, but it still doesn’t work. Do you have the following dynamic library with symbol table?

Best regards,

Annie

  • 0
    TI__Guru**** 397370 points

    Hi Annie,

    This is standard glib library, we dont have debug version of this library.

    Ideally instead of debugging this library, please check where it is crashing and what parameters are going wrong in calling specific glib API..

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    TI__Genius 10295 points

    Hi Brijesh,

    The customer uses the file system packaged by the folder (filesys) in the rdk_3.8 package and downloads it to dm8148. The .so dynamic libraries in its /lib directory are all without symbol table. During gdb debugging, if the standard C library function called by the program is provided by the dynamic library, then the error message of gdb debugging does not display the function name. 

    For example?? (), if the dynamic library has a symbol table, when gdb is debugging, the wrong part is with the function name. EG: memcpy()。 

    The problem that the customer encounters is that when gdb debugs, it is always? ? (), unable to find the place where the program crashed (segment fault or bus error)

    best regards,

    Annie

  • 0 in reply to Annie Liu
    TI__Guru**** 397370 points

    Hi Annie,

    I really don't have debug version of these libraries. 

    I am just wondering, in case of crash, seg fault, bus error, you should atleast get some information, like program counter, stack pointer, etc.. You could use these information to atleast figure out which part of the code is creating issue..  From there on, it should be easy to corner the issue. 

    Regards,

    Brijesh