Author Topic: [debugger] gdb_types.script too limited  (Read 2863 times)

Offline bugmenot

  • Multiple posting newcomer
  • *
  • Posts: 32
[debugger] gdb_types.script too limited
« on: April 22, 2007, 05:39:25 pm »
I wanted to expand the gdb_types.script a bit and found that it was rather hard to use and even very limited.

First of I do not think that it's a good idea to register types based on a regex. For example std::vector<std::string> what does that match? The regex for std::string or std::vector? Also there is a problem with std::string vs std::basic_string. Both describe the same type but match different regexes.

I'd suggest parsing the type in the plugin and then using the non aliased type with namespace prefix to do the lookup. So for example "std::basic_string" or "std::vector". You can use the GDB ptype command to get the exact type of an expression.

Then I don't like the fact that the Evaluate and Parse part are split up into 2 functions. I'd prefer 1 evaluate function which gets the expression, the template arguments of the type and the debugger driver as argument. The expression is needed so that it can do its job. The template arguments allow for specialized output for certain parameters. For example std::basic_string<char, T, U> has a different representation as std::basic_string<int, T, U>.

The driver parameter is needed for two things. First it should dispatch the GDB commands. I had a method in mind which would take a command and give GDB's response as return value.

Then it must be possible to evaluate other expressions. For example std::vector most also format all of it's elements so you need to format vec[0], vec[1] etc. However as the element type can not be known to the evaluation function it must delegate this to the driver. Say a method which takes the expression as parameter, then looks up the type using ptype and dispatches to the correct evaluation function and return the formated value.

Also I'd prefer to see the script return an array value if it contains several value rather than having the evaluation function called several times.