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);
}
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
.
In the script you posted I noticed you called $arg0.Len(). Does this mean the debugger can call member functions?
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...
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.
Does this mean these things would have to be rewritten for each debugger?
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...
That sounds like a good idea.
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.)
See my post above.
But it doesn't use the custom wxString representation, correct?
I'd like vector script to look more like this:
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>)
}
}
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
. 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).
