Re: [cdt-dev] Setting correct state for suspend/resume icons in debugger

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

>Marc
>I haven't done much more with this problem.
>
>If I look at the gdb trace console, I see the following log immediately befoe and after the -exec-interrupt command, so I think gdb has processed the command.

There should be a *stopped event in that output.  Or maybe it follows the part you included?  The *stopped event is sent by GDB to indicate that one or all threads have been suspended.  This is how CDT knows to show the stack frames and enable the resume button.

>The target process does get interrupted, since at that point I can modify the variable the code is looping on using the debugger and resume execution past the loop.

It looks like your GDB has interrupted the process but did not send the necessary *stopped event.

>The only things I'm seeing wrong are that the toolbar icons don't behave properly and the call stack doesn't look right at the time of the interrupt. Once I single step once, then the icons behave properly and the stack looks ok.

That makes sense because after a new step, there is a new *stopped event to indicate that the thread has suspended again.

>---
>370,049 (gdb)
>370,061 37-exec-interrupt --thread-group i1
>370,062 37^done
>370,062 (gdb)
>370,066 38info sources
>370,066 &"info sources\n"
>370,067 ~"Source files for which symbols have been read in:\n\n"
>370,074 ~"elf-init.c, /usr/lib64/gcc/x86_64-suse-linux/4.3/include/stddef.h, /nfs/mmdc/disks/tpi2/us\
>---
>
>I'm not sure where I should be looking for notification of the *stopped event. I do have an IDebugEventSetListener that I registered by calling DebugPlugin.getDefault().addDebugEventListener(), but that does not seem to see any debug events except for some 'create' and 'change' events even when I resume and execution hits a breakpoint. The only events I see are termination events when the program ends.

The above listener is for platform debug events and are usually not what you would look for using DSF.
As for the *stopped event, it is processes automatically by CDT so you don't need to worry about it.  But you need to make sure GDB does send it each time a thread is suspended.

>
>---
>Debug event:
>Source: org.eclipse.cdt.dsf.gdb.launching.GDBProcess@6cd0361a kind 16 detail 0
>Debug event:
>Source: org.eclipse.cdt.dsf.gdb.launching.GDBProcess@6cd0361a kind 4 detail 0
>Debug event:
>Source: org.eclipse.cdt.dsf.gdb.launching.InferiorRuntimeProcess@e820760 kind 16 detail 0
>Debug event:
>Source: org.eclipse.cdt.dsf.gdb.launching.InferiorRuntimeProcess@e820760 kind 4 detail 0
>Debug event:
>Source: org.eclipse.cdt.dsf.gdb.launching.InferiorRuntimeProcess@e820760 kind 16 detail 0
>---
>
>I'm not sure if the -exec-interrupt command is supposed to be used since I did find a comment in org.eclipse.cdt.debug.mi.core.CommandFactory that says -exec-interrupt is not supported, but don't know the context of the comment.

Since you use DSF-GDB, you should not be looking in o.e.cdt.debug.mi*, as this is the old CDI code.
We do support -exec-interrupt for non-stop mode, which you seem to be using.

One thing to make sure of is that the process is actually interrupted when you send -exec-interrupt.  We cannot know this from the few traces shown above.  Maybe the missing *stopped event after -exec-interrupt is that the process was already stopped?

>
>Thanks for looking at this.
>
>Dave
>---- Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
>> Hi David,
>>
>> I see you didn't get an answer yet.  People have been pretty busy with our upcoming release.
>>
>> Did you make any progress on your issue?  If not, let me ask if you are getting a *stopped event after the -exec-interrupt you send.  If you don't then CDT does not realize the program has been interrupted.
>>
>> Marc
>>
>> ________________________________________
>> From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of David Wootton [drwootton@xxxxxxxxxx]
>> Sent: January 13, 2015 11:51 AM
>> To: cdt-dev@eclipse org
>> Subject: [cdt-dev] Setting correct state for suspend/resume icons in debugger
>>
>> I'm trying to implement function in my debugger plugins that is a combination of the CDT debugger attach and launch modes. From the perspective of the CDT debugger, the session looks like a launch, but my plugin is actually attaching to a running process thru an agent that my plugin connects gdb to by having gdb issue a 'target remote' command.
>>
>> I have this working where my plugin establishes the connection, then suspends the running process by issuing an '-exec-interrupt' command. At this point, the user can set breakpoints and resume execution.
>>
>> I am issuing the -exec-interrupt command from the stepRunProgram method in my class that extends StartOrRestartProcessSequence_7_0.
>>
>> The problem is that even though the 'resume' icon is enabled, when I click it, the resume icon is disabled but the 'suspend' icon is not enabled. Once the first breakpoint is reached, the state of the icons is correct and they work correctly.
>>
>> I tried fixing this by getting access to the IDebugTarget object to suspend the application but it seems that it has not been created yet. When I try to access it thru the ILaunch object, its value is null.
>>
>> Then I tried getting access to the IRunControl object and calling its suspend() method,but that resulted in an error message telling me the program was already suspended. I then tried calling the resume() method on the IRunControl object then calling suspend() but that did not help.
>>
>> The other problem I have, maybe related, is that if I click the single step icon and the program suspended somewhere in a library function or then the single step fails with a message from gdb telling me gdb can't determine the bounds of the function. If the program suspends in the application itself, then single step works correctly.
>>
>> I'm looking for suggestion of other ways to approach getting the program into a suspended stare when my plugin connects to it.
>>
>> Thanks
>> Dave
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev