[Lazarus] Debugging shared libraries

[Mark Morgan Lloyd]

Mark Morgan Lloyd wrote:
> Bernd wrote:
>> 2012/9/16 Mark Morgan Lloyd <markMLl.lazarus at telemetry.co.uk>:
>>
>>> 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.

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.

> 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.

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.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]