[Lazarus] Debugging in Libraries.
Hi All: I have encountered a problem doing things that used to work. (Using Lazarus 1.4.4 on Linux and 1.4.2 on Raspbian) Specifically, I can no longer step into subprograms in library units, and when I set a breakpoint in the library code it is colored dull green as opposed to bright red in the main program. Some, but not all, of the library code is implemented using generics. I can't see anything I am doing differently than before (except that I copied the entire source for the program and library from a Raspberry PI, including the configurations. The PI also had this problem). Can anyone give me a hint as to where I should start looking to fix this? Thanks, Don Ziesig -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging in Libraries.
On 18/01/2016 18:34, Donald Ziesig wrote: Hi All: I have encountered a problem doing things that used to work. (Using Lazarus 1.4.4 on Linux and 1.4.2 on Raspbian) Specifically, I can no longer step into subprograms in library units, and when I set a breakpoint in the library code it is colored dull green as opposed to bright red in the main program. Some, but not all, of the library code is implemented using generics. I can't see anything I am doing differently than before (except that I copied the entire source for the program and library from a Raspberry PI, including the configurations. The PI also had this problem). Dull green, usually (check debug output window) means that gdb returned, that there is on code on the requested line/number. With generics, usually the oposite is the case, there are several blocks of code containing the location (and on windows, I have seen gdb handling that, at least in some cases). The question then is, if fpc did generate sufficient debug info or if gdb has an issue. (try stabs and dwarf) ensure you disable "inlining" -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging in Libraries.
On 01/18/2016 03:13 PM, Martin Frb wrote: On 18/01/2016 18:34, Donald Ziesig wrote: Hi All: I have encountered a problem doing things that used to work. (Using Lazarus 1.4.4 on Linux and 1.4.2 on Raspbian) Specifically, I can no longer step into subprograms in library units, and when I set a breakpoint in the library code it is colored dull green as opposed to bright red in the main program. Some, but not all, of the library code is implemented using generics. I can't see anything I am doing differently than before (except that I copied the entire source for the program and library from a Raspberry PI, including the configurations. The PI also had this problem). Dull green, usually (check debug output window) means that gdb returned, that there is on code on the requested line/number. will do. With generics, usually the oposite is the case, there are several blocks of code containing the location (and on windows, I have seen gdb handling that, at least in some cases). come to think of it, IIRC gdb handled generics in windows, but that was back on Lazarus 1.0. I have been working exclusively on Linux and Raspbian for the past 2 years. The question then is, if fpc did generate sufficient debug info or if gdb has an issue. (try stabs and dwarf) will do. Forgot to mention that gdb itself occasionally crashes when working around this code! ensure you disable "inlining" where? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus Martin, Thanks for the pointers. I discovered something since I wrote the last email: gdb works (except for occasional failures in generics) if I compile the whole thing (Run | Cleanup and Build ...) in Linux. Lazarus itself is protected so I have to skip the errors. (I just upgraded this laptop to an SSD so the Cleanup and Build runs faster than just-plain Compile on the original HDD ... Yippy!!!). I haven't tried it on Raspbian yet. Don -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging in Libraries.
On 18/01/2016 20:51, Donald Ziesig wrote:
ensure you disable "inlining"
where?
there may be an option to fpc
I place {$INLINE OFF}(IIRC) in units that need it
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Mark Morgan Lloyd wrote: Bernd wrote: 2012/9/16 Mark Morgan Lloyd markmll.laza...@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] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Mark Morgan Lloyd wrote: Martin wrote: On 19/09/2012 15:04, Mark Morgan Lloyd wrote: Martin wrote: 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
2012/9/16 Mark Morgan Lloyd markmll.laza...@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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Mark Morgan Lloyd wrote: 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On Wed, Sep 19, 2012 at 10:39 AM, Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote: Mark Morgan Lloyd wrote: 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On 16/09/12 14:26, Mark Morgan Lloyd wrote: 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? 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
ik wrote: On Wed, Sep 19, 2012 at 10:39 AM, Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote: Mark Morgan Lloyd wrote: 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. 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Henry Vermaak wrote: On 16/09/12 14:26, Mark Morgan Lloyd wrote: 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? 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On 19/09/2012 09:39, Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: 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 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On 19/09/2012 13:07, Mark Morgan Lloyd wrote: 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Martin wrote: On 19/09/2012 09:39, Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: 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 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. I'd be happy to provide an example program with calls into and out of a .so library. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On 19/09/2012 14:01, Mark Morgan Lloyd wrote: 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. 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Martin wrote: On 19/09/2012 14:01, Mark Morgan Lloyd wrote: 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. 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
On 19/09/2012 15:04, Mark Morgan Lloyd wrote: Martin wrote: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugging shared libraries
Martin wrote: On 19/09/2012 15:04, Mark Morgan Lloyd wrote: Martin wrote: 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Debugging shared libraries
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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
