The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.

[oBFusCATed]

No, unfortunately not. Maybe the contact page posted by scarphin helps.

This is unfortunate.

Note: Change of plans, anyone having this problem and wanting it being fixed should talk to codesourcery's support/dev/gdb maintainers.
I don't intend to support every quirk in every different gdb release.

If you don't want to talk to codesourcery's support your only chance is to patch c::b yourself.

[themaddin]

Okay, that's a clear announcement.

[oBFusCATed]

I could change my mind if the codesourcery people have a valid reason and if they say that they can't change their version of gdb.

[scarphin]

I'll contact them to ask for a bug report address as I'm also concerned with this matter.

@obfuscated: Shall I pm u the address if I find any?

[oBFusCATed]

I would prefer someone else to handle the bug-reporting. But if you can't do it, an e-mail on pm sounds OK.

[scarphin]

I would if I could but I don't think I can handle it. I hope I will someday.

[p2rkw]

Hi,
I just find out that c::b watch scripts doesn't recognize typedefs. It's because 'whatis' gives alias name.
Second 'whatis' is necessary to obtain real type. Part of the log:

Code Select Expand

[debug]> whatis vi
[debug]type = std::vector<int, std::allocator<int> >
[debug]>>>>>>cb_gdb:
[debug]> output &vi
[debug](std::vector<int, std::allocator<int> > *) 0x22fea8>>>>>>cb_gdb:
[debug]> pvector vi
[debug]elem[0]: $7 = 4
[debug]elem[1]: $8 = 56
[debug]elem[2]: $9 = 36
[debug]elem[3]: $10 = 843
[debug]elem[4]: $11 = 265
[debug]elem[5]: $12 = 62
[debug]Vector size = 6
[debug]Vector capacity = 8
[debug]Element type = int
[debug]>>>>>>cb_gdb:
[debug]> whatis vi2
[debug]type = IntVector
[debug]>>>>>>cb_gdb:
[debug]> output &vi2
[debug](IntVector *) 0x22fe9c>>>>>>cb_gdb:
[debug]> output vi2
[debug]{
[debug]  <std::_Vector_base<int, std::allocator<int> >> = {
[debug]    _M_impl = {
[debug]      <std::allocator<int>> = {
[debug]        <__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>},
[debug]      members of std::_Vector_base<int, std::allocator<int> >::_Vector_impl:
[debug]      _M_start = 0x3e27e8,
[debug]      _M_finish = 0x3e2800,
[debug]      _M_end_of_storage = 0x3e2808
[debug]    }
[debug]  }, <No data fields>}>>>>>>cb_gdb:

And what gdb says about IntVector:

Code Select Expand

> whatis IntVector

[debug]> whatis IntVector
[debug]type = std::vector<int, std::allocator<int> >
[debug]>>>>>>cb_gdb:

type = std::vector<int, std::allocator<int> >

What u think about sending second 'whatis' when adding watch?

Currently using 11 February 2012 build (7790) DEBUGGER BRANCH version.

[ollydbg]

c::b watch scripts is quite limited, and I suggest you use the python pretty printer. See this as a reference if you use mingw. http://code.google.com/p/qp-gcc/wiki/GDB

[p2rkw]

nice stuff, printer works very well, but there is another problem:
After "python" command gdb doesn't recognize "end" command, so there's nothing i can do (gdb just hangs) and must terminate gdb via process explorer.

Thanks for help.

[ollydbg]

ok, got it, printer works very well, but there is another problem:
After "python" command gdb doesn't recognize "end" command

I can confirm that enter some command like:

Code Select Expand


python
print 3
end

But it looks like the "end" command does not recognized by gdb. maybe, the "end" command does not send correctly to gdb. so I can't run any command after that.

I just tested gdb under command line, and it works fine, "end" command can successfully end the "python" session, so it looks like something should be fixed in debugger plugin's source. 

BTW: You don't need to manually run some python script in the command line input in the c::b, you just load the pretty printer when you start debugging, and you should disable the build in watch script in the debugger plugin's option dialog.

[ollydbg]

ok, got it, printer works very well, but there is another problem:
After "python" command gdb doesn't recognize "end" command

I can confirm that enter some command like:

Code Select Expand


python
print 3
end

But it looks like the "end" command does not recognized by gdb. maybe, the "end" command does not send correctly to gdb. so I can't run any command after that.

I just tested gdb under command line, and it works fine, "end" command can successfully end the "python" session, so it looks like something should be fixed in debugger plugin's source.  

Ok, from the experience I debug the debugger branch source several days ago, I think the bug is that:
Our debugger plugin do a hand shake on every command you send to gdb, the mechanism is:
1, you send a command to gdb
2, gdb return the value, and restore the gdb's prompt

But in the case that we send command "python", gdb does not return a standard "gdb prompt", but it return a short ">" to wait the user to continuously enter other python commands until it receive "end", so this break the original handshake rule.  

[oBFusCATed]

Just use source. I doubt, I'll fix anything here.

[p2rkw]

Ok, I'll use source.

Why in debugger branch automatic locals and args watching is disabled? I have got both relevant options turned on in debugger settings panel, but plugin doesn't send messages(info locals, info args) when the program is paused. win xp 32.

[oBFusCATed]

Because I've not implemented them back.

[ollydbg]

Ok, I'll use source.

Why in debugger branch automatic locals and args watching is disabled? I have got both relevant options turned on in debugger settings panel, but plugin doesn't send messages(info locals, info args) when the program is paused. win xp 32.

Another reason is that "info locals" will cause the gdb(python enabled, at least under Windows) crash when it try to show an uninitialized local variables. You can search this forum or gdb maillists for some discussion.