Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Custom Watch Script Pluggins
Urxae:
--- Quote from: mandrav on January 24, 2006, 02:05:13 pm ---
--- 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 ---
--- End quote ---
That seems to do most of the work in some weird gdb script though. It looks like the angelscript is mostly just a wrapper because it needs to be done in angelscript ;).
--- Quote from: mandrav on January 24, 2006, 02:17:49 pm ---
--- 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...
--- End quote ---
That opens up some possibilities once the script gets direct access to debugger commands, I think. (Though it's probably possible through that gdb script)
For instance, the use of _M_start isn't portable, but accessing the elements through a standard interface should work for every implementation of std::vector. So []/.operator[]() (if possible), .at() or even iterators (if possible) would make for a much more portable script. And it would be even better if this could be done from a script independent of the compiler and debugger used.
--- Quote ---
--- 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...
--- End quote ---
That sounds like a good idea.
--- Quote ---
--- 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.
--- End quote ---
But it doesn't use the custom wxString representation, correct?
I'd like vector script to look more like this:
--- Code: (cpp) ---void RegisterTypes(DebuggerDriver@ driver)
{
// Notice: No debugger-dependent code
driver.RegisterType(
"StdVector",
"[^[:alnum:]_]*vector<.*",
"ParseStdVector"
);
}
void ParseStdVector(DebuggerDriver@ driver, wxString vecname, DebuggerTree@ tree)
{
for (size_t i = 0; i < vecname.length(); ++i) {
wxString index;
index << "[" << i << "]";
tree.addChild(index, vecname + index); // (<label>, <watch expression>)
}
}
--- End code ---
Which would then work for any type of vector (and use custom representations).
DebuggerTree would be a representation of the tree in the watch window.
Maybe addChild() should have an overload for a single string argument too, to allow complete control over the text being shown.
Note: I don't know much about angelscript, if any syntax is wrong please feel free to ignore that and just get the general idea anyway :P. In particular, if operator overloads don't work please imagine I used .Append() (on copies of the string) and .Printf() instead of << and + ;).
If it's not easy to get vector[0] etc. to be evaluated by the debugger, imagine I used .at() or something.
And if gdb/cdb are advanced enough (especially w.r.t. operator overloads) to allow access to and use of iterators, this might be done in an even cooler way: imagine using only one script for ALL stl containers without special cases being necessary (except maybe std::string and variants, which have a more natural representation). 8)
mandrav:
Update: for those that haven't noticed, I have committed this WIP feature in a new branch (branches/ym_gdb). So if you want to test-drive it, just use this branch.
Ah, almost forgot. This branch has a nifty little bonus: compiler parallel builds :)
rickg22:
Yiannis: I don't think it'd be wise to watch *ALL* the members of a vector. I think it'd be more useful to open a watch window for each vector you want to see (this is also known as "Inspect"). But having vectors of 70,000 items, we'd need "start and end" modifiers, too.
thomas:
I have the feeling the debugger is getting terribly slow... someone should optimize it.
sethjackson:
--- Quote from: thomas on January 25, 2006, 11:20:46 pm ---I have the feeling the debugger is getting terribly slow... someone should optimize it.
--- End quote ---
You are the one to talk with the sig you have. :lol: :lol: :lol:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version