Debugger for FPC lazarus / 6-IDE-CodeTools ---------------------------------------------------------------------- WILL · 2011-01-09 21:22 There seems to be some problems with the GDB debugger that Lazarus is using on non-Windows platforms such as Mac lately. I'm wondering has a FPC-based debugger project been started yet? What would the viability of such a project's development be? I know that the FPC team had worked on and finally got an internal linker going for it's compiler, so what's the chances that the Laz team could work with the FPC team and make an internal debugger that would function better for Lazarus? Not knowing exactly how much work is involved, I'd like to look into this myself to see what are it's chances. ---------------------------------------------------------------------- Laksen · 2011-01-09 21:46 There are a few projects in that direction. There's the fpdebugger that's distributed with lazarus(in some subdir), and there's Duby(here http://sourceforge.net/projects/duby/ ) I don't know what state they're in, but there's still being worked on Duby ---------------------------------------------------------------------- Martin_fr · 2011-01-09 22:09 Duby iirc is based on fpdebug, and the feedback I got a few weeks back was that it is far away from usable... Most of the Mac issues appear to be with 64 bit Macs. It appears that Lazarus only doing carbon, but not cocoa, means that people need to compile there apps into 32 bits. That means they debug a 32 bit app in a 64 bit gdb. Now this should and could work, but it appears to make some issues. Some have been fixed early December, by changes to lazarus itself.. so anyone with a Lazarus older than that => update. But even then, there are several reports of things not working. Unfortunately, people always only say "doesn't work" => you ask them to recompile with certain options, and send the logfiles =>sometimes  you may not get them. If I get the logfiles, I try to look at them, and I try to find out what it is, and try to fix it. I can not guarantee it, I don't have a 64 bit Mac myself.... ---------------------------------------------------------------------- Phil · 2011-01-09 22:33 Martin, I've attached the Console app output of a Laz debug session after compiling Laz with -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG. The last line is where it was when everything hung. Thanks. -Phil ---------------------------------------------------------------------- Martin_fr · 2011-01-09 23:30 Thanks for the log. Interesting the log stops in the middle of a gdb command => is it possible you copied it while lazarus was still running, or you killed lazarus from the process-manager? In those 2 cases the log may not have been flushed. You can try and select "reset debugger" from the run menu. it may not actually work, if the debugger is hanging like this (an issue that needs to be fixed, if the case) but it should add additional output to the log, ensuring it isn't cut off, by an improper file-close. --- it appears you may have no debug info, that should not lead to a hang, but will give problems anyway: From the log Quote1/9/11 5:27:46 PM   [0x0-0xe80e8].laz_svn[3742]   TCompiler.Compile WorkingDir="/Users/phil/laztests/teststringgrid/" CompilerFilename="/usr/local/lib/fpc/2.5.1/ppc386" CompilerParams=" -MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Fi/Users/phil/laztests/teststringgrid/lib/i386-darwin -Fu/Users/phil/laz_svn/lcl/units/i386-darwin -Fu/Users/phil/laz_svn/lcl/units/i386-darwin/carbon -Fu/Users/phil/laz_svn/packager/units/i386-darwin -Fu/Users/phil/ 1/9/11 5:27:46 PM   [0x0-0xe80e8].laz_svn[3742]   laztests/teststringgrid/ -Fu. -FU/Users/phil/laztests/teststringgrid/lib/i386-darwin/ -oproject1 -dLCL -dLCLcarbon project1.lpr" it has -gl, but neither -g -gs nor -gw If that is correct, then you need to add eithe -g or -gw (stabs or dwarf) in the linking tan of the project options. ---- Another thing you can do (*before* you add debug info):  Test some things by hand in gdb. Run:    gdb -i mi lazarus or   gdb -i mi ./lazarus.app/Content/MacOs/lazarus then in gdb type the following. And after each command take special note, that gdb returns *after* all output: "(gdb)" which is the prompt for the next command. It has been seen that gdb omits this prompt (it shouldn't, but...), yet gdb is ready for the next command. However the IDE will never learn this, as it waits forever for that prompt... Here are the commands to try: -gdb-set language pascal info address main => may give warnings, but return something like    "main\" is at 0x1196c in a file compiled without debugging.\n"" convert address to decimal and execute (with correct address) -break-insert -t *72044 => watch out for gdb prompt try execute: ptype TObject just to see and try to find out where it hangs.... ---------- And yes: the error checking, and (it any at all) error msgs returned by the IDE for debugging are not useful at all.... On the todo list....