Author Topic: Why C::B over write gdb's set print element value?  (Read 13763 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Why C::B over write gdb's set print element value?
« on: December 03, 2011, 02:50:23 am »
I see when start gdb, it is:
Code
set print elements -1
This cause some problems, such as when a large String is put as a function argument(maybe, the wxString was loaded from a txt file), this will show all the contents of the String in the debugger log.

So, I think we can leave it as gdb default value is 200.
See:
Print Settings - Debugging with 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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Why C::B over write gdb's set print element value?
« Reply #1 on: December 03, 2011, 02:30:21 pm »
You should say, that it is only for the debugger-branch, not for trunk.

What I don't understand is, what the value of -1 means, because a value of 0 means unlimited.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Why C::B over write gdb's set print element value?
« Reply #2 on: December 03, 2011, 02:36:06 pm »
You should say, that it is only for the debugger-branch, not for trunk.
Oh, sorry, I use only debugger branch these days.
Quote
What I don't understand is, what the value of -1 means, because a value of 0 means unlimited.
Yes, as the gdb document said, it should be 0 (not -1).
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
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Why C::B over write gdb's set print element value?
« Reply #4 on: December 05, 2011, 01:58:30 am »
ollydbg: can you give an example code?
The sample code below:
Quote
int main()
{
    char * p = new char[4000];
    p[1]=4;//set breakpoint here
    return 0;
}

You can just "print p" at the breakpoint, then gdb will show many trash.

Also, if the pointer p is passed to a function call. then when you run a "backtrace", the trash will be shown too.
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: Why C::B over write gdb's set print element value?
« Reply #5 on: January 06, 2012, 12:29:28 am »
OK, I've added a way to control the value of the printed elements.
See Debug -> Information -> Print Elements.
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Why C::B over write gdb's set print element value?
« Reply #6 on: January 06, 2012, 01:50:54 am »
OK, I've added a way to control the value of the printed elements.
See Debug -> Information -> Print Elements.
Thanks for implement this feature, I will test it ASAP.
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Why C::B over write gdb's set print element value?
« Reply #7 on: January 06, 2012, 02:10:10 am »
The variable name:
Code
m_printElements
should be:
Code
m_PrintElements
right?
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: Why C::B over write gdb's set print element value?
« Reply #8 on: January 06, 2012, 08:54:35 am »
I prefer the first version.
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Why C::B over write gdb's set print element value?
« Reply #9 on: January 06, 2012, 09:46:06 am »
I prefer the first version.
Me too.  :)
But the C::B's coding standard (some page in the wiki) said we should use second version.
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Why C::B over write gdb's set print element value?
« Reply #10 on: January 06, 2012, 10:09:41 am »
But the C::B's coding standard (some page in the wiki) said we should use second version.
This one:
http://wiki.codeblocks.org/index.php?title=Coding_style
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ