Author Topic: Custom Watch Script Pluggins  (Read 38212 times)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Custom Watch Script Pluggins
« Reply #30 on: January 25, 2006, 11:48:24 pm »
I 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?
For heaven's sake! Don't tempt him any further, or he'll really start off! :lol:
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Custom Watch Script Pluggins
« Reply #31 on: January 26, 2006, 01:13:38 am »
has somebody tried to profile codeblocks while debugging a program?

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Custom Watch Script Pluggins
« Reply #32 on: January 26, 2006, 03:57:40 am »
I have had the worst time profiling a shared library.  I have gotten as far as generating libdebuggergdb.so.profile .  But I am sure I need a tool called "sprof" to get the actual profile graph.  But I can't find it anywhere.  In other notes the Main Code::Blocks app spends about 30-40% of its time processing events.

EDIT- I found sprof, it was in the libstdc-prof package, but It comes back with a very small mangled named graph.  On windows you could try using AMD Code Analyzer.
« Last Edit: January 26, 2006, 05:15:00 am by Game_Ender »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Custom Watch Script Pluggins
« Reply #33 on: January 27, 2006, 12:52:18 pm »
How does this look?

Code: cpp
// Registers new types with driver
void 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;
}
Be patient!
This bug will be fixed soon...

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Custom Watch Script Pluggins
« Reply #34 on: January 27, 2006, 05:39:12 pm »
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?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Custom Watch Script Pluggins
« Reply #35 on: January 27, 2006, 05:51:51 pm »
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?

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).

BUT

I could add some script constants for the used compiler/debugger so the script could return different data for different compilers.
I believe this will be settled this weekend.
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: Custom Watch Script Pluggins
« Reply #36 on: January 27, 2006, 06:07:41 pm »
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.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Custom Watch Script Pluggins
« Reply #37 on: January 27, 2006, 06:14:52 pm »
Yes, all it comes down to is the STL implementation.
Be patient!
This bug will be fixed soon...

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Custom Watch Script Pluggins
« Reply #38 on: January 27, 2006, 07:31:51 pm »
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.

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.

takeshimiya

  • Guest
Re: Custom Watch Script Pluggins
« Reply #39 on: January 27, 2006, 07:37:25 pm »
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.

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.

A good source would be to see how STL decryptor detects the different stl implementations.

Offline duncanka

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: Custom Watch Script Pluggins
« Reply #40 on: January 27, 2006, 09:13:57 pm »
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?

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).

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Custom Watch Script Pluggins
« Reply #41 on: January 27, 2006, 09:45:04 pm »
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).

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:
Code
output v[0]@100
Be patient!
This bug will be fixed soon...

Offline duncanka

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: Custom Watch Script Pluggins
« Reply #42 on: January 27, 2006, 10:15:18 pm »
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).

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:
Code
output 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?)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Custom Watch Script Pluggins
« Reply #43 on: January 27, 2006, 10:22:56 pm »
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?)

I don't know what this means, performance-wise. I guess I will run some tests and we 'll see.
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Custom Watch Script Pluggins
« Reply #44 on: January 30, 2006, 05:04:21 pm »
Yes, but doesn't operator[] actually ADD elements for STL maps?