oBFusCATed - gdbmi plugin query

[AndrewCot]

Has anyone done any work or played with oBFusCATed  gdbmi plugin in the last say 2 years? If you have does it compile against the latest C::B sources?

The existing source does not build due to C::B SDK a number of years ago (I think it may be 6 years, but I could be totally wrong). I have it building and loading, but not working. I have been looking at it on and off for the last 4 months.

[ollydbg]

I haven't build his gdb-mi plugin recent years. But I did build and use it before.

Basic debugging feature should work OK.

[AndrewCot]

I have forked the code and got it building and running with the C::B SVN code. There were a few changes due to SDK updates and a mod to the GDB breakpoint address decoding to support 64 bit address space.
The code is currently available from https://github.com/acotty/cb_gdbmi , but be aware that the plugin functionality has not changed so it is not complete.

[AndrewCot]

Updated the logging and add extra logging, so the logging in the version from this afternoon (Oz time) is  a heck of allot better.
How did the devs who cloned it go with playing with it? Please raise issues or PR's or add as an issue extra testes that I have not included in the readme.md file so I can make sure all of the tests pass before finishing working on the code.

BTW: Instead of cloning the repo you are better forking the repo and then cloning it.
This post is up for the last commit on 24MAR2022.

[AndrewCot]

I have started fixing bugs I come across by using the small test source code below.

I can do the following:1. set breakpoints
2. run to the first breakpoint3. Continue to the next breakpoint4. step to the next line
5. watch cTest
6. Expand the cTest in the watch window. Fixed a bug that limited the size to 100 in the original code
7. cTest updates between breakpoints or stepping to the next line is working. Fixed a bug that would stop updates after the 9th item.

Code

#include <stdio.h>#include <cstring>

using namespace std;


int main()
{
    char cTest[300];
    memset(cTest, 0x00, 300);
    //              00000000001111111111
    //              01234567890123456789
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "This is a char array");
    strcat(cTest, "END END END END END ");
    printf("Hello world!\n");
    printf("Array: \n%s", cTest);

    getchar();

    return 0;
}

I am slowly making progress. If you cloned the repo or download the source zip over the last few days then I would advise updating your code as the code works allot better now and will continue to improve, so check the git repo for changes every few days.

[AndrewCot]

I have fixed more issues with watches and from my testing I think the watches now look good, but I have not stressed the watches.

I have updated the readme.md to show the pass and fails for the testing I have done (this is the default readme.md that github uses to show on the main page).
At this point in time I think that I can add to my local C::B installation the GDB/MI debugger. This will allow me to use the GDB/MI debugger as my main debugger.

If you need any of the following functionality then you will need to wait for the missing functionality to be added or if you can help with any of it please let me know so the work is not duplicated:

• CPU registers
• Memory display
• debugging console projects where you need to see the console
• Disassembly
• conditional breakpoints

[AndrewCot]

I have updated the Github source with a working CPU registry display. The GDB/MI and GDB command are not the same. The new GDB/MI commands used are the same as CodeLite uses as the old command used does not fit the new way of sending a command and receiving a single response message to process. In the case of the CPU registries there are two GDB/MI command that are needed, one for the names and one for the values.

If you need any of the following functionality then you will need to wait for the missing functionality to be added or if you can help with any of it please let me know so the work is not duplicated:

• Memory display
• debugging console projects where you need to see the console
• Disassembly
• conditional breakpoints

I am now using the GDB/MI debugger to debug the changes I am doing and it's working as expected (aka usable for what works).

[BlueHazzard]

> Memory display
So memory watches are not working?

I will try to test it later...

[AndrewCot]

Watches are working.

No memory display "stuff" is working as there is no code for the "memory dump" or "memory view" dialogs/features.

[AndrewCot]

The missing code to hook up to the GetExamineMemoryDialog appear to be simple and similar to the CPU registry functionality and I can borrow bits of it.

The process I have found the seems to be the fastest is:

• Search the Codelite source code for a keyword and see if there is any lines with a "cmd" in them and they look like the line sends a GDB/MI request.
• Open the file and look at the line found in 1)
• If it is not obvipus what the parameters are lookup the command int he GDB 11.2 manual
• Add the new action and Code up the start() to send the cmd and the OnCommandOutput() to display the result.6) Look at the exsting code for the "dialog" to use or where the data needs to go.
• Code up the rest of the OnCommandOutput().
• Test and mod/fix until the new functionality works like the existing GDB.

I have found that unless you want to read the GDB manual from one end to another searching it can result in finding command that look like they should be used, but there may be other ones that work way better. Found this out with the CPU register commands and wasted a few hours and then looked at how Codelite did it and used the new commands and it worked out allot easier.

[AndrewCot]

The Examine Memory Dialog is now working.

[ollydbg]

AndrewCot, thanks for your contribution!

I will try to build this plugin as soon as possible. 

[AndrewCot]

I would wait as I am making good progress.

The enable/disable pop up menu is now working. Github has the updated source with it in it.

I added the missing code and then spent an hour of debugging as I thought I missed something, but found that the toggling did not work because the "m_enabled = flag;" line in the following function was missing (already in the class and hooked up to the Breakpoint::IsEnabled() function.....

    void Breakpoint::SetEnabled(bool flag)
    {
        m_enabled = flag;
    }

[AndrewCot]

Fixed debugging console projects where you need to see the console. Github updated. 

If you need any of the following functionality then you will need to wait for the missing functionality to be added or if you can help with any of it please let me know so the work is not duplicated:

• Debug -> Memory view dialog
• Disassembly
• conditional breakpoints

Memory dialog info:
The "Memory view window dialog" has "Memory view window" as the title and has tabbed memory view and the data display is shown as two panels.The "Memory examine dialog" has "Memory" as the title and one panel for the data and has a "Go" button. Below the "Address:" static control is "(e.g. 0x401060, or &variable or $$eax)"

[AndrewCot]

I think I have a handle on the cbMemoryView plugin, which hopefully I will be able to get working tomorrow.


@BlueHazzard : Once I get it working and upload the source do you think you test it to try and break it?  The changes are in the GDB/MI debugger as it is missing the AddMemoryRange() function that the plugin requires and the rest of the missing functionality.

[AndrewCot]

To implement the memory range code I need to take time to get more of an understanding of the exisitng code and as such I have started working on the edit breakpoints.
When I started to look at the edit breakpoint functionality I found that there is a bunch of work as the existing dialogs are missing and the existing GDBMI breakpoints are only code only.....with no support for data or function types. With these changes I would not do any testing with the existing as the main breakpoint and code have to change.

Does the existing GDB debugger support function breakpoints? I can see some support, but not enough in my 2 minute check.

[AndrewCot]

I have wired up missing dialogs below so they display like the existing GDB debugger, but they do nothing as there no functionality to use them yet:

• debugger_options_dlg.xrc
• debugger_project_options_dlg.xrc
• edit_watches_dlg.xrc

[BlueHazzard]

I have used data breakpoints in the past.
Never tried function break points, and i think there is no UI to add them, or am i wrong?

[AndrewCot]

That's what I seen with the code for the function breakpoints and was why I was asking as it seemed like it was partially coded and not completed in the existing GDB debugger.  It will end up being the same for the GDB/MI first version as I am porting the same code over with mods to get it working with the new way of doing things in the GDB/MI code.

[AndrewCot]

I know this is a loaded question (I am 99.99% sure the answer is no), but:
Is there a list of GDB features that are missing from the existing GDB debugger? This assumes right or wrong that that GDB is at least 9.1.0. The reason 9.1.0 as it was when version 3 of the GDB/MI version 3  was introduced
GDB/MI version "breaking" changes:


#   GDB     Change
1   5.1     None
2   6.0     The -environment-pwd, -environment-directory and -environment-path
                commands now returns values using the MI output syntax, rather
                than CLI output syntax.
            -var-list-children's children result field is now a list, rather
                than a tuple.
            -var-update's changelist result field is now a list, rather than
                a tuple.
3    9.1    The output of information about multi-location breakpoints has
                changed in the responses to the -break-insert and -break-info
                commands, as well as in the =breakpoint-created and
                =breakpoint-modified events. The multiple locations are now
                placed in a locations field, whose value is a list.

[BlueHazzard]

Are you talking specifically about the MI version, or our debugger plugin in general?

There are a lot missing features (in no particular order), i would like to have:
1) Checkpoints (only available on linux )
2) Display the return value of a function after "step out"
3) Skipping functions
4) record replay (only linux)
5) More (easy) integration of pretty printing

[AndrewCot]

I was talking about the existing GDB debugger plugin, not the MI version.

The list is what I was after. Thanks for the list. I will add the list to the readme.md for future work so it is captured and when I have got the plugin so it has all of the existing functionality and tested I can look at them.
I also need to at some stage do a skim read of the GDB manual and have a look at what Codelite supports to see what could be added in the future, but this is weeks away.

[ollydbg]

Breakpoints persistence is another feature request.

If I remember correctly, we have discussed years ago, also there are a patch(unfinished) in the old patch system: Patches - Code::Blocks History

[AndrewCot]

Thanks.  I found the relevant entry and have added an entry and link in the readme.md so It does not get lost, but as it will save me time as I have to set breakpoints after each change/build/test loop I will get to this one sooner rather than latter.

[AndrewCot]

@ollydbg  I have got basic line breakpoints saving and loading. There was one major issue that took a while to resolve where the RegisterEventSink event cbEVT_PROJECT_OPEN did not work if you have multiple debuggers and the debugger in the project is not the GDB/MI, which it is in my case.  I changed the event to cbEVT_PROJECT_ACTIVATE and the load now works.

[AndrewCot]

I have simple line breakpoints and simple watches now being persistent. By simple I mean non edited, but I save all of the data.
I also fixed a bug that is in the existing GDB debugger where watches are not removed if you close a project. You can see this by open a simple hello world, set a breakpoint, set a watch exit the project and then open the watch window.
Is there any reason why you can add a line break point before starting the debugger, but you need to run the debugger to set a watch?

One major change I have done is to use the tinyxml2 library for the XML file saving and loading, so if you want to build it yourself you will need to build the tinyxml2 library. Attached (in the zip) is my C::B windows main project file with the tinyxml2 library.

[Pecan]

Hmmm, I believe there's already a tinyxml lib built when you build CodeBlocks itself. It's used to read/write all the confs.
And even has a simple but usable api in configmanage.h (I seem to remember).

You could use it to save any debugger info in the extension area of the cbp file.

[AndrewCot]

The code that I used from @ollydbg for save/load used it's own file and the discussion way way back was that it was okay and as such I used the code and updated it to tinyxml2 as tinyxml is depreciated by the developer about 10 years ago.

I will hopefully get to a stage next week where I would like to get some other devs to help test the plugin to see if there is any missing functionality with the exception of the following as I do not expect this to be working next week and some I will leave these for another devs to do:

• Remote debugging.
• No function break point support.
• No display the return value of a function after "step out".
• Testing on Linux or MacOS,  unless you build the plugin yourself and mod the build process. I will leave this for after I complete a LLDB debugger, unless another dev does it first.
• No checkpoints (only available on linux ).
• No Skipping functions - see https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html.
• No Record replay (only linux).

I need to still need complete the following before I unleash it for testing:

• Check the persistent breakpoint and watches work for the different types and if there is anything missing fix it.
• Expand function argument and local variables in the watch window.
• Ability to delete a GDB data watch point (data break point in the C::B GUI)
• Build using the SVN trunk source and modify plugin files to build. My current build project already builds a debugger_gdbmi.cbplugin and the DLL
• Test plugin against last nightly C::B release

[BlueHazzard]

Saving the settings in an external file is a good idea, so they can be added to git ignore files in a multi user environment
We should probably establish an internal standard for names or save them in a .codeblocks folder in the project directory or so...

[AndrewCot]

I will let you run with the file directory/name changes etc as I have enough to work on and the code can be changed at any stage as it does not affect the ability to use GDB/MI for debugging.