* * *

Author Topic: Trying to debug a shared library  (Read 1546 times)

c600g

  • New member
  • *
  • Posts: 9
Trying to debug a shared library
« on: January 22, 2018, 12:44:14 am »
I've been working on a new shared library, and have developed an application which tests it. Is there any way to place a breakpoint in the shared library code and have Lazarus break when running the test application?

Here are some details:
  • Both the shared library and app have been compiled in Debug mode with the default debug information included.
  • In the shared library project, I've set the app as the host application, so that when I Run (F9) the project, the test app executes and everything works as expected.
  • In the test app, I've tried both loading the shared library dynamically (using dynlibs), and just declaring the external function with no difference.
  • I've also tried the "use launching application" Run Parameters... option, which doesn't work (gdb can't find "main" in context).
I'm running Ubuntu 17.10 on x86_64. I've tried both the latest release of lazarus 1.8 / fpc 3.04 as well as trunk (using fpcupdeluxe) with the same results.

Thanks much for any ideas!

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4587
    • wiki
Re: Trying to debug a shared library
« Reply #1 on: January 22, 2018, 04:11:45 am »
This is how it should work. (Have the library project open / Have the "host application" set).

Couple of points.

What happens to the breakpoints, do they turn orange (in the gutter / breakpoint window)?
Or do they stay red?

---------------------

Breakpoints work by unit name only, so if both (lib & host) have a unit1.pas, then there is a problem setting breakpoints.

Either make sure unit name are unique, or compile the host without debug.

Also, while it should work when the host has debug info, there is one limitations. If the host has debug info, exceptions in the lib will not be seen by the debugger. But that should not affect your breakpoints.
Debugging exceptions also only work for static linked dll.

But other than exception, I recently tried this on Fedora with success. (small sample project only)
-------------

How do you make your library available? Do you provide an LD_LIBRARY_PATH? Or do you copy it into libs folder? Are you sure the correct one is loaded?

---------------------
"launching app" should be empty.

If it is not any of the above, can you create a log file:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

c600g

  • New member
  • *
  • Posts: 9
Re: Trying to debug a shared library
« Reply #2 on: January 22, 2018, 04:38:15 pm »
Martin,

Thanks much for the response.

This is how it should work. (Have the library project open / Have the "host application" set).

Done.

What happens to the breakpoints, do they turn orange (in the gutter / breakpoint window)?
Or do they stay red?

When I set a breakpoint in the library, a red circle with a question mark appears in the gutter. When I execute the project (F9), the host application starts up and the gutter breakpoint symbol changes into a red circle with a green checkmark.

Breakpoints work by unit name only, so if both (lib & host) have a unit1.pas, then there is a problem setting breakpoints.

Either make sure unit name are unique, or compile the host without debug.

Not an issue here, as the unit has a unique name.

Also, while it should work when the host has debug info, there is one limitations. If the host has debug info, exceptions in the lib will not be seen by the debugger. But that should not affect your breakpoints.
Debugging exceptions also only work for static linked dll.

Good to know.

How do you make your library available? Do you provide an LD_LIBRARY_PATH? Or do you copy it into libs folder? Are you sure the correct one is loaded?

I set up a symbolic link in /usr/lib that points to the compiled library. Should I instead set "LD_LIBRARY_PATH=." ?

"launching app" should be empty.

Confirmed.

When the test application is compiled, a .dbg file is also created with it (containing debug information, I assume). However, when the library is compiled, there isn't a corresponding .dbg file. Is this normal?

If it is not any of the above, can you create a log file:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

Debug log attached.

Thanks again,
  Alan

c600g

  • New member
  • *
  • Posts: 9
Re: Trying to debug a shared library
« Reply #3 on: January 22, 2018, 04:46:00 pm »
Looking at the debug output (View -> Debug Windows -> Debug Output), I see this as the likely problem:

Code: [Select]
<-symbol-list-lines "/home/alank/work/sce/JSON/module/module_hpml.pas">
^error,msg="-symbol-list-lines: Unknown source file name."

Alan

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4587
    • wiki
Re: Trying to debug a shared library
« Reply #4 on: January 22, 2018, 05:17:22 pm »
The "unknown source" is correct. At that time the source is not yet known. It becomes known when your lib is loaded, and gdb will then update the breakpoint.

Only:
Quote
TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/libscejson.so",target-name="/usr/lib/libscejson.so",host-name="/usr/lib/libscejson.so",symbols-loaded="0",thread-group="i1""

It does not become known. Because gdb does not find your debug info.

Since you have a .dbg file you use external debug info. I never tested this, but it still could work.

I assume at this point, that gdb looks for it in
/usr/lib/libscejson.dbg

But since your lib is a link, the dbg file is not there?

Various solutions to try:
1) ensure the dbg file can be found
2) switch off external debug info
3) use  LD_LIBRARY_PATH (and remove the symlink)


I recommend 3.
Because you can test your lib, without interfering with your real libs.

Just go to run params, and set it as env var. pointing to where your lib is.

-----------
When you try to fix it, watch the logfile, and see if gdb does load any symbols.

-------------
Also check your global options, and check that the following is NOT set
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#SigSegV_-_and_continue_debugging
Though according to the log, it is not set. So should already be ok.





c600g

  • New member
  • *
  • Posts: 9
Re: Trying to debug a shared library
« Reply #5 on: January 22, 2018, 07:24:22 pm »
Martin,

That is what I find interesting (and concerning). I have a .dbg file for the test applicaiton, but not one for the shared library. That is, there is no libscejson.dbg file generated by lazarus / fpc.

I verified that I am building the shared library in Debug mode, and the projects Debugging options for the Debug build mode look correct (Generate debugging info for GDB is checked, type of debug is -gw -godwarfsets, -gl, -Xg, -gh, -gt, plus all checks and assertions turned on).

Alan


c600g

  • New member
  • *
  • Posts: 9
Re: Trying to debug a shared library
« Reply #6 on: January 22, 2018, 07:32:33 pm »
Well, I think I may have found a solution. If I turn off "Use external gdb debug symbols file (-Xg)", then everything works as expected.

There seems to be some issue where fpc isn't able to create the external gdb symbols file.

Thank you very much for pointing me in the right direction, Martin. It is very much appreciated!

Alan

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 4587
    • wiki
Re: Trying to debug a shared library
« Reply #7 on: January 22, 2018, 07:52:31 pm »
There seems to be some issue where fpc isn't able to create the external gdb symbols file.

Maybe worth asking the fpc team ....

c600g

  • New member
  • *
  • Posts: 9
Re: Trying to debug a shared library
« Reply #8 on: January 22, 2018, 08:10:21 pm »
Maybe worth asking the fpc team ....

Opened up an issue on Mantis.

Alan

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus