Review Request 120510: [OS X] make debugger build functional
René J.V. Bertin
rjvbertin at gmail.com
Wed Oct 15 20:51:36 UTC 2014
> On Oct. 9, 2014, 4:24 p.m., Milian Wolff wrote:
> > debuggers/gdb/gdb.cpp, line 165
> > <https://git.reviewboard.kde.org/r/120510/diff/2/?file=317096#file317096line165>
> >
> > couldn't we always kill the debuggee and unit this codebase?
> >
> > also, the indentation is wrong
>
> René J.V. Bertin wrote:
> I suppose we could. The question is whether there was a reason why you didn't always interrupt the debuggee like this. I'm guessing that gdb has the possibility to interrupt the debuggee even if the latter has set to ignore SIGINT.
>
> The strange thing is that I tried (quickly!) to send a SIGINT to a gdb session started by hand on Linux, and that didn't have an effect either, while it does when kdevelop sends the signal. Maybe that gdb ignores SIGINTs when it has an interactive terminal?
Send the SIGINT to the debuggee or to the debugger if the debuggee's PID isn't known (and the debugger's is).
> On Oct. 9, 2014, 4:24 p.m., Milian Wolff wrote:
> > debuggers/gdb/gdb.cpp, line 266
> > <https://git.reviewboard.kde.org/r/120510/diff/2/?file=317096#file317096line266>
> >
> > this will crash when the line has the wrong text format and not contain a comma e.g. please check that.
Checking for `splitLine.size() > 2`
> On Oct. 9, 2014, 4:24 p.m., Milian Wolff wrote:
> > debuggers/gdb/stty.cpp, line 171
> > <https://git.reviewboard.kde.org/r/120510/diff/2/?file=317097#file317097line171>
> >
> > just checking: this code compiled everywhere, even when neither `__sgi__` nor any of the apple macros is defined?
Oops. Probably not. I was so busy being clever making ptyfd a tristate variable that I completely forgot that the code has to be compiled first :)
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120510/#review68163
-----------------------------------------------------------
On Oct. 9, 2014, 6:08 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120510/
> -----------------------------------------------------------
>
> (Updated Oct. 9, 2014, 6:08 p.m.)
>
>
> Review request for KDE Software on Mac OS X and KDevelop.
>
>
> Repository: kdevelop
>
>
> Description
> -------
>
> The conditions are united under OS X / Macports to build kdevelop's debugger component: the changes to the CMake files take this into account.
>
> I have made the required changes in stty.cpp to obtain a pty with r/w permissions - on OS X this is done in a way that shares most code with the SGI code. In order not to duplicate more code than necessary I changed the logic of `ptyfd`'s initial value slightly, allowing to distinguish between uninitialised and error return values.
>
> One has to install an uptodate gdb version (e.g. through MacPorts) and follow the instructions to give it the required permissions to function. Once that's done, the debugger component starts correctly, and appears to communicate with the gdb ("ggdb") slave process.
>
> The gdb version in MacPorts does not react to SIGKILL, which is the signal used by KDevelop to interrupt a programme being debugged. I solved that issue by retrieving the debugged application's pid from the gdb output, and sending the signal to that application instead of to gdb.
>
>
> Diffs
> -----
>
> debuggers/gdb/gdb.h 6f99a60
> debuggers/gdb/gdb.cpp 68e1768
> debuggers/gdb/stty.cpp 736fff4
> debuggers/CMakeLists.txt 8fe222c
> debuggers/gdb/CMakeLists.txt 3d1125c
>
> Diff: https://git.reviewboard.kde.org/r/120510/diff/
>
>
> Testing
> -------
>
> OS X 10.6.8 with kdelibs 4.14.1 and kdesdk git/kde4-legacy . Gdb 7.7.1 from MacPorts, compiled with python 2.7 support.
>
>
> Thanks,
>
> René J.V. Bertin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20141015/b0dae972/attachment.html>
More information about the KDevelop-devel
mailing list