When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.
Quote from: thomas on January 25, 2006, 11:20:46 pmI have the feeling the debugger is getting terribly slow... someone should optimize it.I going to take one of these dangerous stabs in the dark, but does having to comunicate over stdin/stdout put an upper limit on performance? Is that our current bottleneck?
I have the feeling the debugger is getting terribly slow... someone should optimize it.
// Registers new types with drivervoid RegisterTypes(DebuggerDriver@ driver){ driver.RegisterType( // The type's name (must be unique, the debugger driver won't accept duplicates). "STL String", // Regular expression for type matching. "[^[:alnum:]_]*string[^[:alnum:]_]*", // Evaluate function's name (defined below). "Evaluate_StlString", // Parser function's name (defined below). "Parse_StlString" );}// This function tells the driver how to evaluate this type.// a_str contains the variable and result must contain the debugger's command when it returns.void Evaluate_StlString(const wxString& in a_str, wxString& out result){ result = "output " + a_str + ".c_str()";}// This function parses driver's output.// When it returns, the "result" argument contains the parsing result.void Parse_StlString(const wxString& in a_str, wxString& out result){ // nothing needs to be done result = a_str;}
That is very cool, awesome job Mandrav. That looks like it is clean and should be pretty independent. But like mentioned above, when you are doing some complicated like STL vectors and such you might have to use library specific names, is there some way to for script to detect what compiler you are using so it can react accordingly?
You mean, not really based on the compiler, but based on the stl implementation, right? Like detecting if it's libstdc++, stlport, sgi stl, etc.
Quote from: Takeshi Miya on January 27, 2006, 06:07:41 pmYou mean, not really based on the compiler, but based on the stl implementation, right? Like detecting if it's libstdc++, stlport, sgi stl, etc.Would there be an easy way to do this through scripting? I know it will be pretty to easy to check the constants as Mandrav posted above and then you can infer the stl implementation based on the compiler. You would probably have to code some new methods into the debugger so that it searches the library include paths, checks all the linker settings, and checks compiler version to figure out the proper STL version. That would get complicated and might not be worth the effort.
Quote from: Game_Ender on January 27, 2006, 05:39:12 pmThat is very cool, awesome job Mandrav. That looks like it is clean and should be pretty independent. But like mentioned above, when you are doing some complicated like STL vectors and such you might have to use library specific names, is there some way to for script to detect what compiler you are using so it can react accordingly?My tests with std::vector show that there is no other way than using vector._M_impl._M_start to access its elements, which binds the script to a specific compiler implementation (gcc-3.4.4 in this case).
Why can't you just use operator[] for STL vectors? I had no problem accessing vector elements using this syntax in my watches, even if the element I was referencing did not exist (i.e. accessing v[5] didn't cause an access violation even when v only had 1 element allocated).
output v[0]@100
Quote from: duncanka on January 27, 2006, 09:13:57 pmWhy can't you just use operator[] for STL vectors? I had no problem accessing vector elements using this syntax in my watches, even if the element I was referencing did not exist (i.e. accessing v[5] didn't cause an access violation even when v only had 1 element allocated).This is partly true. You see, adding a watch on one vector element is possible with operator[]. But trying to watch a series of vector elements as an array, it doesn't work. You can't do the following, for example (v is a vector), to watch the first 100 elements:Codeoutput v[0]@100
Granted, but even so, wouldn't it be far easier to write a script that just asks GDB for multiple elements using standard operators than to start trying to make a different script for each STL implementation? I guess this would require multiple commands to GDB, but I would think that that would still be simpler to implement. (Maybe have the Evaluate_<type> functions place their results in a wxArrayString, instead of a wxString?)