I've developed a useful convention which allows me to either load a library on demand (via Dynlibs) or to link it statically. This combination allows me to use standard Lazarus debugging techniques to sort out most problems.

However, yesterday's discussion about calling /from/ a dynamically-loaded library /into/ a program binary (other than the main program) raises an interesting question: can Lazarus+gdb be persuaded to trace into a shared library?

Does anybody have any thoughts on this? Martin?

I haven't tried to do it with gdb, however, I'm a big "fan" of printing stuff into log files with much verbose as possible to figure out things.
I hardly use a debugger, and usually use this technique.

Whenever I've tried, Lazarus hasn't had any problems stepping into my libraries (written in C). I usually don't use a debugger, though, so my experience is limited.

Henry

When all else fails... :-)

OK, subsidiary question: is using a logfile or forcing a hypothetical dump (I don't even know what facilities are available these days), is there an easy way of making sense of an arbitrary variable without spending ages finding where its elements are declared in the LCL/FCL/RTL source?

On Linux, if loading a library (written using Lazarus) using DynLibs, I've not managed to get further in than the variable containing a pointer to the entry point. I could be missing something, but I don't think that Lazarus+gdb has a way of pulling in the symbolic info from the .so binary.

I havent tested it my self, but I recall someone saying they had done it. IIRC by using a starter app, via run params.

apparently (on win it requires at least gdb 7.2 or 7.3 (not sure). GDB can set the breakpoints before the lib is loaded, and gdb does then set them on load. (NOT sure if you can use "openlibrary").

It's on a long list of things that I want to test.

According to gdb docs, gdb should. in fact the command for gdb to disable it (even on win) refers to "so" set auto-solib-add mode (the IDE does NOT do that)

THough there are commands to add so files by hand to. Not yet done by the ide

on win gdb does load some info from dll (I saw crashes because of it). but that is dll that are loaded autmatically.

Itmay not work, if you load the dll in your code with openlibrary

I'd be happy to provide an example program with calls into and out of a .so library.

please do.

Though it may be a while till I process it. I am away this week.

No significant urgency from my POV, but it's something that I'm looking at on an ongoing basis. Do you have a Linux development machine with a MIDI interface?

Midi as in the music interface? No |(No either way). I have FC13 in a VirtualBox.

First step for me is to make a basic sampe lib+app (both fpc). That I can add to the automatic tests.

Then more complex cases can be addressed

I'll see what I can find.

2012/9/16 Mark Morgan Lloyd :

interesting question: can Lazarus+gdb be persuaded to trace into a shared library?

While developing the libpurpletorchat plugin (a libpurple plugin) I did not notice any problems debugging the library.

In Lazarus I set /usr/bin/pidgin as host application and then click the run button,
pidgin (written in C) then loads libpurple
libpurple (also written in C) loads my plugin (library written in Free Pascal)

all breakpoints worked, callstack worked and stepping through my library (and even from there back into libpurple) was no problem at all. I did this on Linux/i386, I did not try debugging on windows. I did not notice any debugging problems at all due to the fact that it is a library instead of a program, it worked exceptionally well.

OK, so presumably /usr/bin/pidgin is loading the plugin at runlime (i.e. LoadModule() or whatever) rather than going through a surreptitious recompilation.

I'm working on a test program+library which looks at both dynamic loading and whether an executable (as distinct from a library) can be queried for version information. This doesn't use the LCL etc., and unlike what I (think I) saw earlier I do appear to be able to open an unrelated binary to get version info out of it. More when I know more.

Stepping into a dynamically-loaded shared library appears to work, although the test program I'm working on is only FPC: no LCL etc. I think I've seen it not work in the past, which could be down to platform or GDB version.

Bulk undo there. With a simplified test program, it still looks as though the only case in which an executable (as distinct from a shared library) can be accessed is when it's the main program hence already in memory. That includes attempted indirect access via an extra library layer.

Using Lazarus 1.0, FPC 2.6.0 and GDB 7.0.1 on x86 Linux I've definitely got some capability of stepping into a shared library (i.e. via a pointer of appropriate type etc.). However it doesn't work in all cases, I suspect that there might be something trivial like a requirement that the units defining the library are in the same directory as those of the main program... adding the directory to the debugger paths list doesn't appear to help. There might also be something the debugger really doesn't like particularly if the call is in a thread: I'm getting intermittent X lockups even working on the local console (i.e. rather than X tunneled over SSH).

I've got a convenient test program that doesn't have any particular requirements. Probably the easiest thing would be to tarball it and put it on Pastebin.