Author Topic: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.  (Read 77125 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #30 on: February 22, 2012, 02:21:02 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline themaddin

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #31 on: February 22, 2012, 03:39:11 pm »
Okay, that's a clear announcement.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #32 on: February 22, 2012, 04:39:10 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #33 on: February 22, 2012, 05:23:58 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #34 on: February 22, 2012, 05:26:37 pm »
I would prefer someone else to handle the bug-reporting. But if you can't do it, an e-mail on pm sounds OK.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #35 on: February 22, 2012, 05:39:55 pm »
I would if I could but I don't think I can handle it. I hope I will someday. ;)

Offline p2rkw

  • Almost regular
  • **
  • Posts: 142
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #36 on: February 24, 2012, 01:11:25 am »
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
[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
> 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.
« Last Edit: February 24, 2012, 01:16:59 am by p2rkw »

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #37 on: February 24, 2012, 01:18:37 am »
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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline p2rkw

  • Almost regular
  • **
  • Posts: 142
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #38 on: February 24, 2012, 02:42:41 am »
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.
« Last Edit: February 24, 2012, 02:54:21 am by p2rkw »

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #39 on: February 24, 2012, 02:56:44 am »
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
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.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #40 on: February 24, 2012, 03:11:20 am »
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
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.  :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #41 on: February 24, 2012, 08:50:58 am »
Just use source. I doubt, I'll fix anything here.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline p2rkw

  • Almost regular
  • **
  • Posts: 142
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #42 on: February 24, 2012, 05:49:57 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #43 on: February 24, 2012, 06:37:47 pm »
Because I've not implemented them back.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.
« Reply #44 on: February 25, 2012, 01:39:16 am »
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.