Debug dynamic library (SOLVED)

[BlackShark]

Hi!
I have wasted a lot of time to find out why debugger don't want to see breakpoints in my library code loaded to host application. On Windows it had worked after I added LD_LIBRARY_PATH to environment vars, but I need it on Ubuntu too, where the library raises an exception. I also tried unsuccessfully to add LD_LIBRARY_PATH on Ubuntu. The host application and the lib are placed into own directory, somewhat like: /home/user/Documents/projects/MyProject/Bin

Lazarus 2.2.4, fpc 3.2.2.

Thanx advance.

[Martin_fr]

why debugger don't want to see my library loaded to host application.

Just to make sure I understand this correct:

- You have 2 projects. Each in a folder of its own.
  1 project => app that loads the library
  1 project => the library

- You app can open the library. That is your app does find the dll/so and loads it, and gets a handle.

=> But the debugger does not ....
... find the pas source file for the code in the dll (so you get an assembler view)
... stop at breakpoints (or exceptions) in the dll
... ???

On Windows it had worked after I added LD_LIBRARY_PATH to environment vars

"LD" sounds like Linux..., but maybe I am not up to date on this.

In any case, this is about your app seeing the dll => that is your app will get a valid handle on executing "OpenLibrary" (or similar).

If, you don't get a valid handle when trying to load the library, then that does not sound like a debugger issue

If you do get a valid handle, then read on...

First of all there are differences between GDB and FpDebug backends.  (Actually in Lazarus 2.2.x only the GDB backend will be able to deal with libraries / even in 2.3 GDB will still fare better).

Fpdebug (even in 2.3) will not deal well with breakpoints in the dll. It will step into the dll, and once you stepped in you can set breakpoints, but not before.
Gdb (if not too old) should do ok with such breakpoints.



The first issue to avoid is having matching/same unit names in the app and the dll. This will (99% likely) confuse the debugger. So make sure all unit names across app and lib are distinct.

Next it depends what you experience, if you step into (or stop at a breakpoint in a) unit of the library => what happens?
If the debugger does not know where the pas sources are, it should ask. Does it?
Menu: Tools > Option > Debugger > General: "Additional search path" and add where the pas files are.


Also you have 2 ways to debug a library.
1) Open the app project.lpi, and run this
2) Open the lib project.lpi, and under menu: Run>Run_Params set the "host application" to the app project.exe

Overall, debugging libraries is still very basic and somewhat cumbersome.

[BlackShark]

Just to make sure I understand this correct:

- You have 2 projects. Each in a folder of its own.
  1 project => app that loads the library
  1 project => the library

- You app can open the library. That is your app does find the dll/so and loads it, and gets a handle.

=> But the debugger does not ....
... find the pas source file for the code in the dll (so you get an assembler view)
... stop at breakpoints (or exceptions) in the dll
... ???

Yes, that's right

...First of all there are differences between GDB and FpDebug backends...

First I tried GDB, but it was falling with an error. FpDebug nice debugged the host application, but when it called lib exported methods, it showed an assembler (are there any plans to fix it?). I had tried again DGB after I read your advice/response and it worked!!! GDB is not the best tool, but thanks it I could find the bug . 
Thank you very mach!

[Martin_fr]

FpDebug nice debugged the host application, but when it called lib exported methods, it showed an assembler (are there any plans to fix it?).

It's partly fixed in the git main branch. (Lazarus 2.3). And yes there are plans, but not yet sure for which release.


https://wiki.freepascal.org/Debugger_Status#Other
3 entries for "Debugging libraries"