Gecko dotNET Bugs and Requests

[dcx2]

I think he accidentally had the debugger option unchecked.  What he would prefer is a dialog box that said "hey, dumbass, turn on the debugger in Gecko OS", instead of just freezing without any explanation.

[dcx2]

And the single line control for memviewer has a problem similar to the one the whole page control had, I noticed this after being brought to an address by clicking show mem in the breakpoint tab

I'm not sure what "single line control" you're referencing.  The scrollbar next to the DataGridView?  The arrows next to the TextBox?  Keyboard keys?

When you set a read breakpoint on a file name and then cancel it and try to go to the memviewer if it's currently at the location of said file name it will freeze the game & Gecko.NET and then give an error message about loosing connection with the gecko, when you reconnect it will take you to the memviewer tab but the game will still be frozen, if you click run game the same thing will happen when you try to go back to the breakpoint tab except the game will unfreeze

Setting a read (or read/write) breakpoint and, canceling it and then going to the memory viewer will result in Gecko.NET losing connection.
The game will be paused (maybe because Gecko.NET itself will trigger the breakpoint?) and Gecko.NET will bring up 2 popups about reconnecting.

Exactly, for some reason the Cancel Breakpoint does not seem to work very well.  If you do a read breakpoint and you go to Memory Viewer, it will break on itself.  You should be able to hit run or reconnect to fix it.

I don't understand what "read breakpoint on a file name" means.  We set breakpoints on addresses don't we...?

I can also confirm the step over bug.

Step Over worked for me yesterday.  Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl.  It essentially "steps over" function calls without going into them.

Also, the step out function steps through the code until it sees "blr", but wouldn't it be faster to set a breakpoint on the LR?

It would be faster, unless you already hit a bl in the current function, in which case that bl has overwritten the value in the LR.  However, in that case you could peek at the stack for the LR save word (where the function prologue stored the LR so that the function can safely bl).  However, a function doesn't need to store the LR save word if it doesn't call any functions itself, so you can't always peek at the stack.  There are even some functions with multiple return paths (i.e. multiple blr's), so you can't even search for the next blr.

Unfortunately, the safest way to Step Out is to repeatedly Step Over until you encounter a blr.  Also, if Step Over doesn't work then Step Out wouldn't work either.

[wiiztec]

I'm not sure what "single line control" you're referencing.  The scrollbar next to the DataGridView?  The arrows next to the TextBox?  Keyboard keys?

The scrollbar

Exactly, for some reason the Cancel Breakpoint does not seem to work very well.  If you do a read breakpoint and you go to Memory Viewer, it will break on itself.  You should be able to hit run or reconnect to fix it.

I don't understand what "read breakpoint on a file name" means.  We set breakpoints on addresses don't we...?

You have to hit run and then the breakpoint tab to fix it, I meant I set a breakpoint on the address at which a file name was loaded into memory I've since found out that the problem is not exclusive to such circumstances

Step Over worked for me yesterday.  Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl.  It essentially "steps over" function calls without going into them..

I thought it just stepped over any instruction or at least all jumps/branches

[Romaap]

I can also confirm the step over bug.

Step Over worked for me yesterday.  Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl.  It essentially "steps over" function calls without going into them.

I remember it didn't step over the branch created by a C2 code, but I dont remember if it did that for a "bl".

Also, the step out function steps through the code until it sees "blr", but wouldn't it be faster to set a breakpoint on the LR?

It would be faster, unless you already hit a bl in the current function, in which case that bl has overwritten the value in the LR.  However, in that case you could peek at the stack for the LR save word (where the function prologue stored the LR so that the function can safely bl).  However, a function doesn't need to store the LR save word if it doesn't call any functions itself, so you can't always peek at the stack.  There are even some functions with multiple return paths (i.e. multiple blr's), so you can't even search for the next blr.

Unfortunately, the safest way to Step Out is to repeatedly Step Over until you encounter a blr.  Also, if Step Over doesn't work then Step Out wouldn't work either.

Yeah, I didn't think about that.

[dcx2]

I remember it didn't step over the branch created by a C2 code, but I dont remember if it did that for a "bl".

A C2 code doesn't create a function call...it's more like a detour.  The code handler has to set up custom branches to and from the hooked address.  It does this because not all functions push the LR on the stack, so bl is not safe.  But it's a bit awkward because of the to and from branches.

Normally, that's what the Link Register is for.  It creates a link from the function caller to the callee, so that when the callee is done it can return back to the caller.  Step Over does not really skip over code, preventing it from being executed.  The processor still executes the bl, does all the work, and blr's back.  We just don't have to put up with watching all the stuff inbetween the bl and blr.

[James0x57]

I've been using this the last 3 days, love it! Thanks guys! :)
The ability to copy the text on the mem viewer and disassembler is great! Code tab is also much improved. :D


Few questions/requests though, since that's what the thread's for:
1) Could you make it tell me when there are no results, please? :P
2) How do you do a multi poke? It didn't work on WiiRDGUI so I was really hoping to have it back since GCN hacking....
3) Another "yes please" for an undo button in the search. ;)
4) Breakpoint Condition for Address -making it not break on some address x is super useful. (if it's there, I just looked over it, my bad..)
5) Take/Show/Hide Snapshot in memory viewer would be a nice convenience. Tis useful when searching around pointers to similar objects.

[Romaap]

I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from.
It could be just like the step out, but it should stop when a specified register is used.

Anyway, I would still like to thank you guys for the effort.
Its a great app :)

[dcx2]

1) Could you make it tell me when there are no results, please? :P
2) How do you do a multi poke? It didn't work on WiiRDGUI so I was really hoping to have it back since GCN hacking....
3) Another "yes please" for an undo button in the search. ;)
4) Breakpoint Condition for Address -making it not break on some address x is super useful. (if it's there, I just looked over it, my bad..)
5) Take/Show/Hide Snapshot in memory viewer would be a nice convenience. Tis useful when searching around pointers to similar objects.

1) I will put in a message box that indicates a lack of results
2) Select as many addresses as you want (using ctrl or shift), then right-click -> poke
3) I'll see what I can do about undo.  Loading/Saving searches can be slow and I'm not sure why.
4) Don't-Break-On-Address-Xyz can be accomplished with SRR0 != conditions.
5) I would like to eventually add snapshot support to Memory Viewer, and the Breakpoint tab.

I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from.

Hm...I like this idea.  Repeatedly Step Into, until a specified register is a source or destination operand.

Any implementation suggestions?  Pop up a dialog box with a dropdown that allows you to select what register you are interested in?  What could we call this?  "Step Until"?

[Romaap]

I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from.

Hm...I like this idea.  Repeatedly Step Into, until a specified register is a source or destination operand.

Any implementation suggestions?  Pop up a dialog box with a dropdown that allows you to select what register you are interested in?  What could we call this?  "Step Until"?

Step Until sound good, and yeah I was thinking of a popup with the controls.
It could have a dropdown with the registers and maybe a selection for destination/source/both ?

[James0x57]

That is a good idea!

Thanks dcx2! One thing though: Multi poke doesn't work. (for me) When I do what you said, it just makes the address part of the poke red and empty and I can't poke..

[dcx2]

Doh!  You must be using a test build with AddressTextBoxes instead of generic TextBoxes.  They validate inputs to make sure they're legitimate addresses - and when you Multi-Poke it fills the textbox with MP, which isn't a legitimate address.  (they also have a history, kinda like the web browser address bar)  I'll have to improve multi-poke support in the test builds.

The official 0.61 binary on the first post of this thread should do multi-poke correctly, because it still uses generic TextBoxes.

[James0x57]

Ah thank you!

There is no wild card search value (that I'm aware of). Could you add that, please? =)

[dcx2]

Wild card search value?  Could you elaborate on this, because I don't think I've ever seen this feature in WiiRDGUI.

[James0x57]

It works in WiiRDGUI too, just checked.

32 bit search for: ?A?A?A00
returns results like: 1A2A7A00, 0A0A0A00,AAAAAA00
and so forth.

[dcx2]

So they're like don't-cares?  Normally you would want bit-level resolution for specifying such things, but I guess nibble-level resolution would be okay.

I might make a Mask field to do this, so we get the bit-level resolution.