Set Next Statement (Debugging)

[BlackSerpent]

Hello!

I would like to know if there is a way to do "Set Next Statement" like in Visual Studio.

doing Set Next Statement is actually changing the Instruction Pointer while the program is under 'Pause'.

In a more intuitive description: Move the yellow marker to whatever line I want.

Thanks!

[BlackSerpent]

to make things clear - I do not mean the "Run to Cursor". Run to cursor is some sort of a breakpoint.

for example: (a silly example showing what I mean)

Code

   int k = 1;
>  k = 9;
   k = 19;
   k = 119;
   if (k==1) {...}

move the > cursor to the if line, ignoring the statements above, while k keeps its original value - 1.

[ollydbg]

I know what's your meaning.
I don't think it is necessary since I have using Visual Studio for over 4 years without touch this functionality.

[nanyu]

as i known, we can set the next statement by modify the value of "CPU Register: eip".
but i can't add watch "$pc" in c::b. when i did it, the debug process abort.

---
and can we send  cmd "jump " to gdb to set the next statement??  i don't known how to do this in c::b.

[Ceniza]

I use Visual C++ and Delphi in the office, and I DO use that feature when debugging in both of them. It's handy to have it now that I started using it, when used well of course. Since I never saw it in Code::Blocks, I never felt the need

It's also nice that you can drag&drop the arrow to set the next instruction to be executed.

I don't know if GDB has that instruction, but that's what Google is for.

I may check today, but right now I have other things to do. If you find something, do not hesitate in posting it here.

[Ceniza]

There's a patch proposed for KDevelop that shows how to do it here.

Basically, the idea is to use two instructions:

tbreak filename:line
jump filename:line

I just tried with a very simple test file similar to yours and it works just fine.

It's probably not even that hard to add to the debugger plugin, plus a button in the toolbar and a menu entry. What's missing is an icon. Visual Studio uses a blue arrow. We could use a 50% red one instead :wink:

Adding drag&drop would be... I don't know. I haven't fiddled with that myself, neither have I toyed much with Scintilla.

BTW, now that I was testing that, wasn't there a proposal to have a field or a dockable window (with the field) for the "Send user command to debugger"? It's not like it's going to be the most used feature either, but it would be nice to have it too

Patches, as usual, are more than welcomed. If I have some more time today I may even give it a try.

[Jenna]

It's probably not even that hard to add to the debugger plugin, plus a button in the toolbar and a menu entry. What's missing is an icon. Visual Studio uses a blue arrow. We could use a 50% red one instead :wink:

It could also be implemented without a marker like "run to cursor". It can be called "jump to cursor".

We should be aware, that jumping can be dangerous:

The jump command does not change the current stack frame, or the stack
pointer, or the contents of any memory location or any register other than the
program counter. If line linespec is in a different function from the one cur-
rently executing, the results may be bizarre if the two functions expect different
patterns of arguments or of local variables. For this reason, the jump command
requests confirmation if the specified line is not in the function currently exe-
cuting. However, even bizarre results are predictable if you are well acquainted
with the machine-language code of your program.

(quote from gdb-docs)

We need to parse the output of gdb and open a Yes-No-Messagebox if gdb requests confirmation.

[Ceniza]

I just saw the message when trying to jump to another function. Having to interact like that with the debugger sucks.

About being dangerous... of course. It's like messing with the registers or the memory. In fact, it's messing with a register.

It doesn't really matter much if it's implemented the same way as "run to cursor" and calling it "jump to cursor". What's going to be nasty is having to parse GDB's output for yet another message.

[thomas]

We need to parse the output of gdb and open a Yes-No-Messagebox if gdb requests confirmation.

Oh please don't. Those  stupid messageboxes all over are so darn annoying.

See, if someone jumps from an arbitrary location in the program to another arbitrary location, this is bound to yield unpredictable results. Every programmer should know that, since it's obvious, and if someone doesn't know, he shouldn't be programming. This is like editing memory pages of a running process in a hex editor... it may work fine, but it's an incredibly stupid thing to do, and if it blows off your right arm, then it's your own fault

So either the IDE should not have such a function at all, or it should require you to explicitely enable the button in the settings (with a warning, if you will). However, it should not warn you every single time you press the button, because the behaviour is so obviously undefined that you have to be able to figure yourself.

[Jenna]

We need to parse the output of gdb and open a Yes-No-Messagebox if gdb requests confirmation.

Oh please don't. Those  stupid messageboxes all over are so darn annoying.

See, if someone jumps from an arbitrary location in the program to another arbitrary location, this is bound to yield unpredictable results. Every programmer should know that, since it's obvious, and if someone doesn't know, he shouldn't be programming. This is like editing memory pages of a running process in a hex editor... it may work fine, but it's an incredibly stupid thing to do, and if it blows off your right arm, then it's your own fault

So either the IDE should not have such a function at all, or it should require you to explicitely enable the button in the settings (with a warning, if you will). However, it should not warn you every single time you press the button, because the behaviour is so obviously undefined that you have to be able to figure yourself.

You are right, that the user is responsible for what he is doing.

And if such a feature is used often it's really annoying to click away such a dialog box all the times.

But explicitley enabling this button in the setings, is something I don't like either, because it's not really intuitive.

But what's abaout an annoying dialog if it is used.
Than the user can decide if he wants to be warned the next time.

By the way, we set "confirm off", when we start gdb, so we wouldn't get this warning message in any cases.

[BlackSerpent]

Thanks for the replys!

VC++ has that feature working perfectly.

It probably has algorithms that compensate for the stuff that are supposed to keep the program sane.

I guessed that the reason that this feature is missing is because it is difficult to be implemented.

[Ceniza]

I think the reason this feature is missing is because the Don (who designed the debugger plugin) and the community (that just wants more and more stuff) did not consider it before. It's two instructions and a confirmation away to be implemented.

The only thing I recall from using it in VS was the information dialog when I tried to set it in another frame saying that it would first switch to that frame. Either that, or I have dreams about VS showing me messages.

[oBFusCATed]

For the interested parties, I've implemented this feature in the debugger branch: http://forums.codeblocks.org/index.php/topic,10908.msg82294.html#msg82294

p.s. there is not warning dialog, because gdb is in always yes mode