| Summary: | CDT debugger fails to suspend target | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Cameron Stevens <cameron.stevens> |
| Component: | cdt-debug-cdi-gdb | Assignee: | Alex Chapiro <achapiro> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alain, cebarne2, nobody |
| Version: | 1.2 | ||
| Target Milestone: | 2.1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Cameron Stevens
The problem is that, you will have the same behaviour using command line gdb. If you CTRL-C it will not be suspended. Maybe we can try to bypass gdb and drop the signal ourself, I do not cygwin at hand to test but we'll give a try later this week. Meanwhile, when you are in gdb, attach and hit ctrl-c does is stop ? It may be an error on our part, I wan to confirm this. gdb displays similar behavior in stand-alone mode. That is, CTRL+C does not cause the target to suspend. > gdb displays similar behavior in stand-alone mode. That is, CTRL+C does not
> cause the target to suspend.
Then how do you manage, to suspend the application ?
And we will try to "mimic" the scheme.
You have to understand the underlying debugger backend
__is__ gdb, if it fails, we will 8-)
Yup, I realize that we're at gdb's mercy here, and hence this may be beyond the control of CDT. On the other hand, this IS extremely relevent to CDT adoption, which is why I posted the bug here. I really want to see CDT succeed as a viable C++ development platform. I think its amazing how far its come already, and look forward to 2.0. However, if I can't perform a basic operation like setting breakpoints whenever I want, it becomes a non-starter, even if gdb is the underlying cause of the problem. Back to your question. The application suspends fine when I first attach to it, either in gdb or from Eclipse. Thus, any breakpoints I set IN ADVANCE, or set at the time it is first suspended, are capable of being hit later. I then resume the application. Once breakpoints are subsequently hit, I can once again modify/add/remove breakpoints. I haven't discovered a gdb mechanism to suspend the application while it is running, thus I don't have any suggestions for what techniques CDT could mimic. I'm happy to post a bug against gdb as well if this will help. However, I'm really not a gdb expert, haven't downloaded the source code, etc. This is another reason I posted the bug here. This issue relates to CDT adoption, so I felt you might have a vested interest in looking into it, and would probably be much better versed in gdb that I. On the other hand, I'm certainly not trying to unload my problems on you, so let me know if you wish me to pursue this directly with gdb. > This issue relates to CDT adoption, so I
> felt you might have a vested interest in looking into it, and would probably be
> much better versed in gdb that I.
Yes. Alex agreed to take a look at it.
Since the process is attach we may find a way to suspend the debugger
Redirected to Alex, for further look.
PR was not targeted to any particular release. Changing target milestone to 2.1 Hi Alex, you own this and it hasn't been touched since February. Any resolution? Thanks. It was fixed. Cameron please reopen if it still happens or turn to verified if you agree it was fix. |