• Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 494 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux CCS M8.5 issue...no remote GDB breakpoint/symbols/variables in dynamically loaded shared libraries...

Joe Cossette
Intellectual 780 points

When I load a shared library via dlopen() and retrieve an entry point via dlsym(), and then call the entry point, I get the source code and can step into/step over Ok, but I cannot set GDB breakpoints normally by clicking on the source line number,  It sets a little red ball, but no check mark. If I go to the GDB console I can set a GDB breakpoint by manually issuing a command like the following:

    b afp.c:487

This tells GDB to set a breakpoint in the source file afp.c at source line 487.  If I then Resume it will stop when it hits the breakpoint.  If I also enter other GDB commands in the console against functions in the shared library like "info func ptzfid_protocol_init" GDB displays the function prototype.  GDB command "info address ptzfid_protocol_init" elicits a GDB response indicating that this is a function, as well as displaying it's correct address.

There are also no variables available in the Variables dialog.  Also, even in the disassembly window there is no interspersed source.

It's clear that GDB is capable of symbolically debugging dynamically loaded shared libraries, and there is a wealth of information on the internet to indicate that this is so.

The version of GDB/GDBREMOTE I'm using is v7.3.1, the most current version.

 

  • TI__Guru**** 171519 points

    Joe,

    A quick cleanup check: are you properly selecting the type of breakpoints from the IDE? Check:

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/100988/354274.aspx#354274

    Regards,

    Rafael

  • in reply to desouza
    Intellectual 780 points

    Ok...after a bit more checking this is what I found out:

    1) If I don't have the source file added to my C project, whenever I step into a function in the dynamically loaded module the correct source file pops up in an editor window, but the default breakpoint type is CCS. Variables don't appear to be working when this occurs. But I can set the breakpoint type to C/C++ and then breakpoints work as expected. And variables also appear to work. Once I've done this these settings appear to be "sticky", that is to say, it appears like they are saved in the project/debug config because if I terminate the debug sessions and relaunch it the breakpoint type is still set to C/C++.  Even if I terminate CCS, when I restart it and re-run the debug config the breakpoint type is still set to C/C++.

    2) But there is an issue with the Modules window regardless of the above procedure. If the Modules window is open during the dynamic loading process the new module does not appear in the window (i.e. If I step over or run over the dlopen() function). If the Modules window is not open during the loading process, but after the module is dynamically loaded I then open the Modules window the module is listed properly.

     

  • in reply to Joe Cossette
    TI__Genius 16570 points

    re 1). Once the breakpoint type is set, it is persisted in workspace for each window type, i.e editor, disassembly, outline, etc...

    re 2) The content provided in the modules view for a gdb debug session is provided by CDT/GDB integration. I am guessing that there is no event or CDT didn't subscribed to dynamic module load event (if there is one). 

    Regards,
    Patrick