gdb-7.2 on Mac OS X 64 bit

[caleb9]

Hi,
since the gdb version 6.3.50 which installs with XCode 3.2.5 on Mac OS X freezes (http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Debug_session_freezes) I decided to give it a try with the new gdb instaled through MacPorts. The version currently available is gdb-7.2. I'm fairly new to Mac so I'm not sure how this should work, however it seems I have both versions installed next to each other. When I execute

Code: [Select]

gdb -version it says 6.3.50 (the executable file is in /usr/bin/gdb). I've figured that the binary for the new one is /opt/local/bin/fsf-gdb since it yields version 7.2 and I couldn't find any other executable like that... So I've set the path up in lazarus Environment -> Options -> Debugger but even the default empty project doesn't run - it shows message window "Failed to load file: /tmp/project1.app: Inappropriate ioctl for device."
When run from command line I get

Code: [Select]

bash-3.2$ fsf-gdb project1
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10.7.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /private/tmp/project1...machoread.c:170: internal-error: macho_symtab_read: Assertion `oso_file != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)Any ideas?
Bunch of info: I'm running Snow Leopard 10.6.7 64bit, FPC 2.4.2 (32bit used for compiling the project) and Lazarus 0.9.30 (if that's relevant). As you can see the GDB was compiled for 64bit architecture (so was the old one as it seems) - I'll give it a try to compile it in 32bit and see what happens.
Thanks in advance :]

[Martin_fr]

afaik the macport gdb doesn't know how to resolve the exe from the app bundle.

use "run parameters" and specify the actual executable inside the app bundle.(it's still in the app bundle, so it should still run normally)

[caleb9]

Thanks Martin_fr. I won't have access to Mac till Monday but I'll give it a try then and report back if it worked.

[Martin_fr]

Did you also see the part about recompiling the IDE with -dDBG_WITH_TIMEOUT on the wiki?

Though that does not yet catch every possible location.

If you still keep hanging you can get a lot of insight into what happens between lazarus and gdb by recompilng with the following defines. This is far more verbose than the contnet of the "debug output" window. (And this is also a good start for reporting problems, especially if the debugger hangs on a command)

DBG_VERBOSE
DBGMI_QUEUE_DEBUG

If you use them, you need to start the IDE either from console (and watch the console) or with a logfile .

Starting from console means to call the exe, inside the app-bundle (it's still inside the app bundle, so it will behave fine)

[caleb9]

afaik the macport gdb doesn't know how to resolve the exe from the app bundle.

use "run parameters" and specify the actual executable inside the app bundle.(it's still in the app bundle, so it should still run normally)

I've set up Run -> Run -> Run parameters -> Host application to my project's executable. Now the fsf-gdb (7.2) shows me a window with the following message:

Debugger error
Ooops, the debugger entered the error state
Save your work now !
Hit  Stop, and hope the best, we're pulling the plug.

It is still a dummy project so I guess it's not an error on my side. I'll try your further suggestions now.

Edit:

Did you also see the part about recompiling the IDE with -dDBG_WITH_TIMEOUT on the wiki?

Though that does not yet catch every possible location.

Tried that now, seems I'm unlucky to hit one of these situations as the debugger still freezes at my breakpoint (gdb-6.3.50) Actually it seems to freeze anywhere I set the breakpoint - in a dummy project I can "step into", "resume" and so on, but in my real project it just doesn't react to these...

[caleb9]

I'm wondering if this can have something to do with MacPorts' GDB being compiled for 64bit arch while Lazarus project compiles to 32bit. However so far I've been unable to force macports to build gdb in 32bit mode - I've set variants to -universal in /opt/local/etc/macports/variants.conf and build_arch to i386 in /opt/local/etc/macports/macports.conf, but GDB still shows that it was built for x86_64

Code: [Select]

bash-3.2$ fsf-gdb -version
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10.7.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.unless I'm misunderstanding something.

[Martin_fr]

Indeed Lazarus 0.9.28 would have assumed from a 64 bit gdb, that the exe was too. In  0.9.30 checks have been added, but I have only 32 bit, so I cannot test myself.
The 64bit gdb itself should also be able to handle it.

The other issue is that the normal feedback "ups ... error state" is not helpful. (obviously, and it's on the todo list to improve hat)

In order to help I need some more information.

There are 2 ways:
1)
Menu: "View", sub-menu: "debug windows": "debug output"

This window must be opened before you run your executable. (if you do a 2nd run, you can clear the content, by select all / del)

Run the app, then copy the entire content of that window, zip, and attach it.

It contains all communication between lazarus and gdb.
If you do not like to post it public ([xxx] is "at" / without the <>): <lazarus> [xxx] <mfriebe>.<de>

2) if you recompiled with (especially the 2nd)
-dDBG_VERBOSE  -dDBGMI_QUEUE_DEBUG

then run lazarus with --debug-log=/some/file

You can delete any part of the file, before the debugger starts.
Then send the file.

It contains the same info, but has additional info about the internal doings of the debugger.

[caleb9]

Attached is the output of method 2 :]
Thanks!

Edit: This is the output of Lazarus with gdb-7.2.

[Martin_fr]

Ah, yes. I forgot.

it seems the MacPort GDB doesn't like stabs (or at least fpc's stabs)

Stabs is a format for debug info, used by default if you tick "debug info (-g)"

On the linking page tick "use dwarf (-gw)"

If you compile your app, and you see any msgs from the linker (they will be hidden in the msg-view, but should be on console/in the log-file) that say "unknown stabs", then something still has stabs, and it will not work.

If so then you may have to recompile your entire LCL (recompile Lazarus / "Tools"=> "configure build lazarus") with the option "-gw"
(or "-gw -godwarfsets", if you use a lot of sets in your source)

Look for the msg in the logfile:
[Debugger] Log output: &"machoread.c:170: internal-error: macho_symtab_read: Assertion `oso_file != NULL' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."

--- btw, your logfile does not seem to have -dDBGMI_QUEUE_DEBUG enabled, (you can specify this in the options field, if you rebuild the ide). It doesn't change any behaviour (at least shouldn't), it just at's a real lot of debug-output)


###EDIT:
Done some more tests (with 32 bit).
The above only works for very simple apps.
For more complex apps, I have not yet been able to figure out a way to make MacPort gdb run. Sorry.

Maybe if you supply a log, for the gdb 6.3, so I can see where it hangs...

the output should have plenty of gdb commands (-data-evaluate-expression / break-insert , "gdb stopped reason", ....

[caleb9]

Thanks for the feedback first of all. :]

On the linking page tick "use dwarf (-gw)"

If you compile your app, and you see any msgs from the linker (they will be hidden in the msg-view, but should be on console/in the log-file) that say "unknown stabs", then something still has stabs, and it will not work.

If so then you may have to recompile your entire LCL (recompile Lazarus / "Tools"=> "configure build lazarus") with the option "-gw"
(or "-gw -godwarfsets", if you use a lot of sets in your source)

Ok so I started lazarus with --debug-log, set -gw in Project Options->Linking and "Build all" my project, grepped the logfile but the word "stab" doesn't occur at all. Neither in the dummy project nor in the real one. Only message from the linker is "ld: warning: -macosx_version_min not specificed, assuming 10.6"...

--- btw, your logfile does not seem to have -dDBGMI_QUEUE_DEBUG enabled, (you can specify this in the options field, if you rebuild the ide). It doesn't change any behaviour (at least shouldn't), it just at's a real lot of debug-output)

Maybe something's wrong then as I've set that option for sure (also before I've sent you the output) and recompiled the IDE, but let me revise, maybe you can notice something: in Tools->Configure "Build Lazarus"->Options I entered "-dDBG_VERBOSE  -dDBGMI_QUEUE_DEBUG" (without quotations) and hit "Build". I'll give it another go to make sure.

#Edit:
Recompiled the IDE with these options set for sure, I also toggled on "Verbose" and "Debug" in Defines panel (-dDebug -dVerbose) to make sure. The output is however still the same as the one I attached to my previous post :(.
#End of edit

###EDIT:
Done some more tests (with 32 bit).
The above only works for very simple apps.
For more complex apps, I have not yet been able to figure out a way to make MacPort gdb run. Sorry.

Maybe if you supply a log, for the gdb 6.3, so I can see where it hangs...

the output should have plenty of gdb commands (-data-evaluate-expression / break-insert , "gdb stopped reason", ....

Will do.

[Martin_fr]

Maybe something's wrong then as I've set that option for sure (also before I've sent you the output) and recompiled the IDE, but let me revise, maybe you can notice something: in Tools->Configure "Build Lazarus"->Options I entered "-dDBG_VERBOSE  -dDBGMI_QUEUE_DEBUG" (without quotations) and hit "Build". I'll give it another go to make sure.

#Edit:
Recompiled the IDE with these options set for sure, I also toggled on "Verbose" and "Debug" in Defines panel (-dDebug -dVerbose) to make sure. The output is however still the same as the one I attached to my previous post .
#End of edit

The options field is the correct place, and so are the options you entered.

1) try "clean all", since the units did not change, recompilation must be forced.
Recompilation should take a minute or two

2) Maybe you still run the old exe.
I don't know for sure about OSX, but on linux, normal users do not have write access to the folder with the lazarus installation.
So a recompiled exe is stored in /user/name/.lazarus/
(If you use start lazarus command, it should find the correct one. startlazarus also accepts and forwards the log-file argument)

Check the file date of your lazarus exe.

---
I completely forgot about 2, because I always work on svn checkouts, so I always have write access to all folders...

[caleb9]

You're right - after toggling "Clean all" in "Configure 'Build Lazarus'" I have now a lot more debug (a side note - I couldn't compile Lazarus after cleaning all - something causes an error but I just toggled it off again and then it builds using probably the old version of this specific component - however the part responsible for debug output gets recompiled apparently) so I'm attaching the extended debug log for gdb-7.2 on a dummy project.

Another side note: on Mac user apparently has rw access to /Developer/lazarus where it's installed, and I think I have paths all figured correctly (went through compiling and executing from different directories some time ago already ;)). I come from Linux myself and just recently been forced to work on Mac, and FPC/Lazarus on this platform seems very underdeveloped in comparison to Linux... :/

Edit: I also attached gdb72dummy_debug2.zip which contains debug for gdb-72 with LCL clean-rebuild with -gw -godwarfsets, and the project itself with -gw although I can't see any stab messages there. Odd thing is that the debugger seems to hang when using these options - the form of a dummy project doesn't appear, and this happens for both gdb-6.3 and 7.2.

[Martin_fr]

The problem is, the bug in MacPort gdb can not be worked around easily (probably not at all). It probably needs to be fixed around by the MacPort developers.

The problem is that debug info for pascal and c just look different. They are both encoded by the same standards (stabs or dwarf), but they use different elements of that standard. MacPort gdb, doesn't seem to be able to read all of them;

As for Lazarus development, the only thing that can be done, is identifying commands that gdb does not deal with, and either avoid them, or improve detection of errors(e.g. timeouts => actually, they are completely missing responses, so with timeout they are recoverable)

Since GDB 7.x fails on attempting to load the executable, well there is no way to skip that.


As far as I have observed, 6.3.5 at least reliably starts up, loads and runs the exe.

However evaluation of certain expressions (as part of watches, or as part of the IDE's handling of exception or other things) leads to gdb 6.3.5 not responding (or not as expected)).
gdb finishes the command. But it does for some reason not print a command prompt afterwards => and the IDE waits for it.

So by identifying those commands, and ensure the IDE can detect the missing prompt via timeout (it does verify operation by sending another command), it should be possible to get 6.3.5 working. (hopefully)

If you attach the same log for GDB 6.3.5 , there may be a better chance.

I believe your 6.3.5 experience matched the description, debugging would just "hang" forever.

[caleb9]

Ok so seems I'll have to stick with 6.3.5 for now and hope I don't stumble upon more situations where the timeout doesn't work - but now that I think about it, maybe I didn't clean-rebuilt the IDE and the timeout wasn't actually there. For the sake of research I attach log from 6.3.5 as you suggested - both Lazarus and the dummy project compiled with -gw. I managed to execute it - I think before it was not working because I forgot to clean the run parameters for 6.3.5 (7.2 required "host application" to be set) - in other words it didn't hang now. In the meantime I managed to solve the bug that was causing all the trouble in my real project by other means, and now I actually can't make it to hang the debugger ...but it's just a matter of time that I get another one like that.

Anyway thanks again for all the help! :]

[Martin_fr]

Ok, well good luck.

and if you get a hang, just send the logfile (so best to keep you lazarus running with logfile / rotate it from time to time...)

and then I can look into it.