Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Custom Watch Script Pluggins
mandrav:
--- Quote ---It looks like it gives a query to run and defines a function to parse the output. Would it not be simpler (and possibly more powerful) if the script could ask the debugger driver to run certain queries? That way you can run multiple queries and the script logic can even dynamically adjust which ones and/or how many times. It also allows for more abstraction from the actual queries, which might allow the same scripts to be used by both GDB and CDB.
--- End quote ---
(I 'm gonna use gdb examples here)
Before evaluating a variable, the driver runs a "whatis <var>" which gives the variable's type. This is then checked for matches by any script-registered type using the script-supplied regular expression.
If a script that matches is found, the previously defined "print_<typename>" gdb function is called. That would be "print_wxstring" in the above code case.
When we receive output from this command, the script's parse function (GDB_ParseWXString in the code above) is called.
The second argument will be filled with the result in a format similar to gdb's "output" command (the watches parsing works with this). So it will always be a string. I can elaborate on the format if you want it...
The first argument that is passed to the script is more interesting though. It contains the driver's output of the previously run command (print_wxstring in this case).
Depending on print_wxstring's definition, this string might be multiline but it doesn't matter. The parser function (GDB_ParseWXString) should parse it correctly and put the parsing result in the second function argument we talked about earlier.
All the above mean that you can parse practically whatever. If you want, I can post an example for parsing a std::vector. It's perfectly possible with this setup.
Finally, I haven't settled with this design yet. I 'm still evaluating it...
Thanks for the feedback though :)
killerbot:
--- Quote ---All the above mean that you can parse practically whatever. If you want, I can post an example for parsing a std::vector. It's perfectly possible with this setup.
--- End quote ---
Please do.
Urxae:
In the script you posted I noticed you called $arg0.Len(). Does this mean the debugger can call member functions? That would be a great help when generalizing/porting scripts to multiple implementations (such as different standard libraries, or different versions of libraries with the same interface but different implementation), as long as variables of that type can be completely described by calls to member functions (which is true for a lot of types).
--- Quote from: mandrav on January 24, 2006, 12:03:27 pm ---
--- Quote ---It looks like it gives a query to run and defines a function to parse the output. Would it not be simpler (and possibly more powerful) if the script could ask the debugger driver to run certain queries? That way you can run multiple queries and the script logic can even dynamically adjust which ones and/or how many times. It also allows for more abstraction from the actual queries, which might allow the same scripts to be used by both GDB and CDB.
--- End quote ---
(I 'm gonna use gdb examples here)
Before evaluating a variable, the driver runs a "whatis <var>" which gives the variable's type. This is then checked for matches by any script-registered type using the script-supplied regular expression.
If a script that matches is found, the previously defined "print_<typename>" gdb function is called. That would be "print_wxstring" in the above code case.
When we receive output from this command, the script's parse function (GDB_ParseWXString in the code above) is called.
--- End quote ---
Does this mean these things would have to be rewritten for each debugger? Is there maybe a way to abstract this a bit more, even if it's just the most basic functionality?
If the output needs to be in the same representation as a debugger output command, maybe the script should have access to some helper functions that produce the output in a more high-level way. This would not only be helpful in providing a more understandable way to create the output, but also allows for more uniform access to output formats for different debuggers.
This would basically entail some helper functions and/or classes. (Does AngelScript even have classes?)
--- Quote ---The second argument will be filled with the result in a format similar to gdb's "output" command (the watches parsing works with this). So it will always be a string. I can elaborate on the format if you want it...
--- End quote ---
Hmm... I don't know much about gdb, but does this mean you could already write such a generic vector parsing script that would be parsed by C::B into a tree representation? (taking into account the scripts for the element type etc.)
--- Quote ---The first argument that is passed to the script is more interesting though. It contains the driver's output of the previously run command (print_wxstring in this case).
Depending on print_wxstring's definition, this string might be multiline but it doesn't matter. The parser function (GDB_ParseWXString) should parse it correctly and put the parsing result in the second function argument we talked about earlier.
--- End quote ---
But some types may not be easy to print in one command, especially for people who've never used gdb directly (like me). I'm especially thinking about containers here.
Here a few parsing helper functions/classes would probably also be helpful. (Presumably, different debuggers write out different formats)
--- Quote ---All the above mean that you can parse practically whatever. If you want, I can post an example for parsing a std::vector. It's perfectly possible with this setup.
--- End quote ---
I guess that already answers one of my questions. As often noted on these forums, you guys are fast :lol:.
Seriously, that would probably be quite instructional, especially with extensive comments that explain everything.
--- Quote ---Finally, I haven't settled with this design yet. I 'm still evaluating it...
Thanks for the feedback though :)
--- End quote ---
I presumed you hadn't settled on it yet. Actually, that's why I gave the feedback. I just wanted to make sure this would work for more complex structures that are best presented as multiple values. Best to do so before anything is settled on, right? ;)
mandrav:
--- Quote from: killerbot on January 24, 2006, 12:26:58 pm ---
--- Quote ---All the above mean that you can parse practically whatever. If you want, I can post an example for parsing a std::vector. It's perfectly possible with this setup.
--- End quote ---
Please do.
--- End quote ---
Here it is:
--- Code: (cpp) ---void RegisterTypes(DebuggerDriver@ driver)
{
driver.RegisterType(
"StdVector",
"[^[:alnum:]_]*vector<.*",
"GDB_ParseStdVector",
"set $vec = ($arg0)\n"
"set $vec_size = $vec->_M_impl._M_finish - $vec->_M_impl._M_start\n"
"if ($vec_size != 0)\n"
" set $i = 0\n"
" while ($i < $vec_size)\n"
" p *($vec->_M_impl._M_start+$i)\n"
" set $i++\n"
" end\n"
"end\n"
);
}
void GDB_ParseStdVector(const wxString& in a_str, wxString& out result)
{
result = "{" + a_str + "}";
result.Replace("\n", ",", true);
}
--- End code ---
EDIT: The attached image shows a std::vector<float> being watched.
Still needs some work, but as you see it is possible :)
[attachment deleted by admin]
mandrav:
--- Quote ---In the script you posted I noticed you called $arg0.Len(). Does this mean the debugger can call member functions?
--- End quote ---
Yes, you can call functions, do casts, basically whatever the language allows. As long as the debugger has full info on the type that is...
--- Quote ---Does this mean these things would have to be rewritten for each debugger?
--- End quote ---
As it is now, yes. But I plan change this. I 'm rethinking the whole process. In the std::vector example I posted above, I doubt it would work with wxStrings (well it would work, but not using the print_wxstring function).
So maybe I will expose some debugger commands to the scripts so they can call the debugger directly as needed. I 'm thinking it over...
--- Quote ---Hmm... I don't know much about gdb, but does this mean you could already write such a generic vector parsing script that would be parsed by C::B into a tree representation? (taking into account the scripts for the element type etc.)
--- End quote ---
See my post above.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version