I'm trying to get KDevelop's internal debugger working on OS X, currently in the kde4-legacy branch because KF5 is not yet available on the Mac. The code builds, but launching the debugger freezes kdevelop in the `waitpid` call in `GDBDebugger::STTY::findTTY`. The child process spawned by the fork call just earlier prints out a large list of error messages and hangs too, because it accesses CoreFoundation functionality that isn't available in the child of a `fork` call. Is there an alternative to start the executable launched with ```C++ QString path = KStandardDirs::locate("exe", BASE_CHOWN); execle(QFile::encodeName(path), BASE_CHOWN, grant?"--grant":"--revoke", (void *)0, NULL); ``` in the `fork()` child? Or should I look for a way to prevent the need for calling `chowntty` by setting `needGrantPty=false` in a legitimate way? If the latter, I'd appreciate some feedback and context, as this is not something I'm particularly experienced with. Reproducible: Always Steps to Reproduce: 1. build Debugger on OS X 2. Configure a Debug launch and start it Actual Results: the environment hangs and has to be killed Expected Results: debugger works as expected
As described in RR https://git.reviewboard.kde.org/r/120510/ I have gotten a bit further, and circumvented the fork/exec issue the way it's intended: claim a pty. This now works and gdb is launched. I cannot communicate with it, however, and am now wondering if this is because of the choice of signals: ```C++ queueCmd(new GDBCommand(GDBMI::SignalHandle, "SIG32 pass nostop noprint")); queueCmd(new GDBCommand(GDBMI::SignalHandle, "SIG41 pass nostop noprint")); queueCmd(new GDBCommand(GDBMI::SignalHandle, "SIG42 pass nostop noprint")); queueCmd(new GDBCommand(GDBMI::SignalHandle, "SIG43 pass nostop noprint")); ``` Can anyone please explain the choice of those signals and their significance on Linux?
Dear Rene, what's the status on this? Does gdb on Mac OS X work, and what about the KF5 branch? By the way, I agree that those signal handlers look dodgy. They have been in the code since it was imported into the repository, but I see no good justification for them. However, it seems highly unlikely that any issues you're having are related, and rather than shooting blindly, you should first check whether removing those four commands actually helps.
Hi Nicolai, The status is that I've finally migrated to OS X 10.9 and am still trying to figure out how to get gdb to function. From time to time, when I remember it is apparently not impossible... I've been asking for some feedback on the lldb ML, and while there is a lldb-mi interface to the library and debug server that do the actual work it isn't part of Apple's toolchain. Building it requires to build all of llvm first, apparently, which is somewhat beyond what my machine can handle in a reasonable time. As to the KF5 branch ... it seems the QStandardPaths obstacle is tougher to solve than we expected so the day I'll work on it is still far off. By then I hope someone else will have started to work on a plugin that communicates with the lldb debug library & server directly, without need for the standalone debugger executable.
decreasing importance, OS X is simply not supported yet
As a matter of fact, the new lldb debugger plugin is more or less functional on OS X too. It's a bit of a pity that it uses the lldb-mi driver instead of implementing a direct, dedicated driver but as a first start it's not bad at all. As to this ticket, I think it could be closed. Back when I reported the issue I was probably still running OS X 10.6, on which gdb worked. On more recent versions gdb is supported less and less well. IOW, pursuing the gdb plugin doesn't make much sense anymore.
Thanks for that feedback, happy to hear lldb integration is working on OS X, too.
It does, at least to some extent but I'm tempted to say it works better for me on OS X than on Linux. I haven't tested it in depth and as far as I've run into issues it's hard to tell which are due to the newness of the plugin, which to the fact it leverages lldb-mi and which to it running on OS X. WHat I can tell is that it's slow (but so is Apple's own lldb from the cli, or even gdb on Linux; lots of data to load and parse I presume). I also encounter regular lldb-mi crashes even when I'm not doing anything (timeouts waiting for input from the plugin?) and sometimes I get an "unexpected reply" error from the plugin which then puts the debug session in some unknown state, obliging me to kill it. Building the lldb plugin does require building and installing lldb because Apple didn't always provide lldb-mi, and I think even now they don't ship the necessary headers and stuff with Xcode. Getting that lldb to function requires code-signing it, which for now requires some manual and painstakingly following of instructions. I'm hoping we can get that sorted out within MacPorts. The biggest hurdle to using this more frequently is the fact attaching to a running process doesn't work (rather, detecting of running processes doesn't work; the list remains empty). When I tried to launch and debug KDevelop itself in order to figure out where the "missing 'pt' translation dictionary" error came from I ended up with a debuggee session that was deadlocked somewhere in the initial steps of loading a QMake project. I ended up using Qt Creator, which does manage to attach to a running application. One thing that could be improved is automatic recognition of app bundle targets. Currently, it attempts to execute the .app directory instead of the bundle exec. That's stuff for a different ticket though.
ok, closing the gdb stuff as unmaintained then on os x