#543 cbEVT_DEBUGGER_PAUSED not fired

[bluehazzard]

The cbEVT_DEBUGGER_PAUSED event is not fired from gdb if the debugger comes to a halt.
I expect to get this event as soon as the debugger stops for a breakpoint, signal or other cuase.

But i don't get this event in any case. It is generated only once in

void DebuggerGDB::DoBreak(bool temporary)

and i don't see where this function is called from within the debugger.

From searching in the forum it seems that they are pretty old, and never where implemented properly :
http://forums.codeblocks.org/index.php/topic,9904.15.html
http://forums.codeblocks.org/index.php?topic=9668.0
http://forums.codeblocks.org/index.php/topic,8577.15.html

[Teodor Petrov]

Why do you need to handle this event?

[bluehazzard]

1) They are in the sdk and should work....
2) I am working on implementing some embedded debugging help plugin(s). The plugin(s) has to send some commands to the debugger and this even would really help to determine if the debugger is halted and ready to accept input

[bluehazzard]

fix is in this ticket: https://sourceforge.net/p/codeblocks/tickets/619/

[Teodor Petrov]

I'm testing this patch and I don't like it. The event is sent every time the run queue is empty. Is this the goal of the patch? Shouldn't the event be some symetrical to an extent to the continued event? I think this was the original idea behind the event.

You've implemented something like a debugger_ready event, which is a different kind of event.

I'm looking at your plugin and I'm not sure why you want to update watches on every paused event (debugger_ready). This means that you'll do it on every addition of breakpoints for example.

I think you need to do something like:
void DbgCmd_UpdateWatchesTree::Action()
{
Manager::Get()->GetDebuggerManager()->GetWatchesDialog()->UpdateWatches();
}

Probably the whole way the debugger notifies the UI should be reworked to use events and not direct method calls.

Another thing you could use is the DEBUGGER_CURSOR_CHANGED event (you'll have to make it part of the sdk).

[bluehazzard]

The event is sent every time the run queue is empty. Is this the goal of the patch? Shouldn't the event be some symetrical to an extent to the continued event? I think this was the original idea behind the event.

This was the intention. The event should help to update the plugin state after commands of the debugger are executed. I agree the naming is not right, but the event was there and not used, and i was thinking that introducing a new event seemed even more difficult to bring past the devs, then "fixing" a bugouse event ;) (no bad harm intended)

I'm looking at your plugin and I'm not sure why you want to update watches on every paused event (debugger_ready). This means that you'll do it on every addition of breakpoints for example.

The intention was to keep this event universal, not just tailored for my plugin. A kind UPDATE_UI event, because the debugger changed something. For example if the user changes a variable in the watches window, this would change also a memory entry, but will not get fired by cursor_changed, or debugger_paused (if only fired if the debugger was halted after a continue)

I think you need to do something like:
void DbgCmd_UpdateWatchesTree::Action()
{
Manager::Get()->GetDebuggerManager()->GetWatchesDialog()->UpdateWatches();
}

I am not sure what do you want to tell me here

Probably the whole way the debugger notifies the UI should be reworked to use events and not direct method calls.

This seems reasonable. If i should put some work into this, it would help if you open a ticket with some specifications to start.

[Teodor Petrov]

This was the intention. The event should help to update the plugin state after commands of the debugger are executed. I agree the naming is not right, but the event was there and not used, and i was thinking that introducing a new event seemed even more difficult to bring past the devs, then "fixing" a bugouse event ;) (no bad harm intended)

OK, The name should be different in this case. But I'd prefer a better solution.

The intention was to keep this event universal, not just tailored for my plugin. A kind UPDATE_UI event, because the debugger changed something. For example if the user changes a variable in the watches window, this would change also a memory entry, but will not get fired by cursor_changed, or debugger_paused (if only fired if the debugger was halted after a continue)

You said nothing about my breakpoints example. How would you solve this problem? I don't think it is a good idea to refresh your UI every time the debugger is idle. This is not a good design or user experience.

I am not sure what do you want to tell me here

That the normal watches window uses this mechanism for update and you should use something similar.

This seems reasonable. If i should put some work into this, it would help if you open a ticket with some specifications to start.

I cannot do a specification. For me it will be easier to implement the mechanism directly than to write a specification. But I cannot test your plugin, so if I do something it might not be suitable for your plugin.

If I were you I'd consider two approaches:
1. Make the debugger send cursor changed events and cpu registers/watches change events. You could probably make single event with some flags in it.
2. Make the debugger send updateui events when it has updated the watches window.

[bluehazzard]

How about this:
cbEVT_DEBUGGER_QUEUE_EMPTY
i want this event because the debugger plugin can not know everything a possible plugin wants to do. For example reset a microcontroller, after all commands are issued...

cbEVT_DEBUGGER_UPDATE_UI with flags:
CURSOR_CHANGED --> If the cursor has moved
WATCHES_CHANGED --> [0]
CUSTOM_COMMAND --> [1]
.... (maybe breakpoint added and backtrace updated?)

[0]
Fired anytime something memory related has changed:
1) Debugger halted
2) Variable changed by user
My problem with this is, that the debugger plugin somehow has to know if some values have changed, and i don't know how the plugin should detected that. For example if the user types a custom command directly to the debugger

[1]
If we begin to rework the debugger api i would like to add some queue where a plugin can queue commands and a call back function. The debugger plugin runs this commands and executes the callback function with the result. This event would be called to inform other plugins that a user command has fired (either by this queue or by the user itself from the command line). Maybe we can add the plugin/user command in the event. What to do with it, is up to the plugin....
Why do i want this? As i mentioned a lot times before, i would like to extend codeblocks with embedded functionality. Mostly the IDE communicate with the uC through the debugger. For this "monitor" commands are used, for example "monitor reset" to reset the uC. For more monitor commands see for example https://www.segger.com/downloads/jlink/UM08001 chapter 3.3.3 page 62. With a simple queue interface this would be pretty easy. But this would be topic for a other Ticket.

I cannot do a specification. For me it will be easier to implement the mechanism directly than to write a specification. But I cannot test your plugin, so if I do something it might not be suitable for your plugin.

Well and i am getting frustrated. I code for hours and then it is called "i don't like it, make it somehow different". I don't mind the critic, 99% of the time it is correct, but sometimes i would like to have a better path in what direction the code should go. The argument "if i specify it more i could write the code by myself" is somehow lame, because you don't do it ;) (and i don't condemn that, this is free time over all), but you know what you want, even more you know what you don't want and you can describe it.

[Teodor Petrov]

cbEVT_DEBUGGER_QUEUE_EMPTY - I prefer if we can implement this svd viewer without this event. I think it is possible and this should be our last resort. This event allows too much ways to abuse the debugger.

cbEVT_DEBUGGER_UPDATE_UI - probably name this cbEVT_DEBUGGER_STATE_CHANGE. cbEVT_DEBUGGER_UPDATE_UI should be used to specify the exact window that needs to be updated. So calls like Manager::Get()->GetDebuggerManager()->GetWatchesDialog()->UpdateWatches(); would be replaced with sending message calls. Also STATE_CHANGE event will be sent when the debugger detects that something changed (like the current position, stopping on breakpoints, etc), so you can handle it and then do some debugger calls which queue commands. When these commands execute the debugger will send UPDATE_UI events, so your plugin can update the ui.

[1] As I've stated many times already I'd prefer if we don't introduce APIs which introduce tight coupling between plugins. Adding a cue means that one plugin must know how to work with another plugin and in the current debugger case it must know when the driver is gdb-driver and not cdb-driver. But lets discuss this when the svd-viewer is working with a trunk version of cb.

About the specification: I cannot give you the exact path forward. API design is about experimentation and iteration. This is the only way to achieve good design. You cannot think about the cases up front.
About not doing changes to the debugger myself:
1. I'm working on more broken pieces of cb, IMO
2. I'm not using remote debugging, so I don't have incentive to sort this out at the moment. At the moment I review patches and sort debugger problems which are easy to solve.

If you want to continue discussing this I think it is better to go to the forum, because the UI in sf.net is terrible. :(

[Teodor Petrov]

Have you decided what to do about this problem?

[bluehazzard]

I create a branch with a partial working event api

https://github.com/bluehazzard/codeblocks_sf/tree/fix/ticket/543/1

Not all events are fired. And i am not sure if the internal windows (like watches) should use also the event api (i don't think so... This api is only for plugins as far as i can see...)

I created also a plugin to test this api on a real world sample:
https://github.com/bluehazzard/cbMemoryView

[Teodor Petrov]

Are you talking about the last 4 commits in this branch? Or are you talking about the full memory watches issue? The last 4 commits are confusing terminology a bit, but this is fine if this is the direction you want to follow I can clean it up. :)

If you're not going to implement the pause event I guess this ticket should be closed and the discussion should move to the other ticket.

[bluehazzard]

I want to add the PAUSE event, but i think this needs also some work and i wanted first to get some confirmation i am on the right path. Also i will not have time for a few weeks so if you find time to implement the rest , feel free to go on...

Here is a cleaned up branch with only the event system, without memory things...
https://github.com/bluehazzard/codeblocks_sf/tree/fix/ticket/543/2

i made the first branch, because i needed some piece of software to test this and so i combined two tickets/branches to generate the plugin...

[bluehazzard]

any feedback on this?

[Teodor Petrov]

It requires cleanup, but I haven't found the time to do them. Also I don't remember the details. :)