Author Topic: Visual "optimalisation" of watched variables when debbuging  (Read 1386 times)

bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Visual "optimalisation" of watched variables when debbuging
« on: March 26, 2014, 08:01:13 am »
Hello there,
Is there a way to turn off this visual "optimalisation" of watched items while debbuging? It is quite iritating sometimes. Is there a way for slickedit to show whole watched variables instead of only the part that differs in some way? I have attached i screen where it is showed.

EDIT: Also i have noticed that sometimes when watching a variable (for example an char example[128]), in the watch window i only see limited nr of members (in this one for example from index 0 to 60). And then i have to open the memory window to watch whole variable... This is kind of iritating.
« Last Edit: March 26, 2014, 11:25:56 am by bremenpl »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2207
  • Hero Points: 275
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #1 on: March 26, 2014, 12:20:41 pm »
We display arrays the way GDB hands them to us.

In the case of character arrays, GDB typically truncates those at a NULL character.  I think most people would find it more irritating to have character arrays expand past the NULL character.

GDB supports numerous options for printing arrays.  You could set up a .gdbinit in order to set up various options.  Whether the GDB/MI interface will honor a single one of them is anybody's guess.

https://sourceware.org/gdb/onlinedocs/gdb/Print-Settings.html

The two options you might want to try changing are:

set print repeats 1000
set print null-stop off


bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #2 on: March 26, 2014, 12:33:28 pm »
I have tried adding tgo gdb file the options you provided but it had no effect. Its not really about chars and null characters it was just an example. Please look at my screen. I have a variable:
Code: [Select]
unsigned char FeederFlashPagesBuffer[112][128];For me it means i shuld be abble to see every single byte from 0 to 127 112 times. In my window i do see 112 vectors but every of that vector has only 36 members instead of 128... This is what i do not understand. Before this variable was set with data (all zero) i have only seen 24 members of each vector.
The point is i dont see all watched data :/
« Last Edit: March 26, 2014, 12:35:02 pm by bremenpl »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2207
  • Hero Points: 275
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #3 on: March 26, 2014, 12:48:06 pm »
By default, SlickEdit launches GDB with the "-nx" option to specify NOT to read the user's .gdbinit file.  If you know what you are doing, you can set up your own GDB configuration with a -x <config_file> argument to tell it to read a .gdbinit file.  Debug > Debugger Options > GDB Configurations...

If you have not done this, then that is probably why the commands were ignored.

As for the chars and NULL termination.  It is about chars, because the type of your array is unsigned char.

You may also want to try adding "set print elements 2000" to your .gdbinit.  However, this can effect performance, so use with caution.

bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #4 on: March 26, 2014, 12:50:30 pm »
I am using gdb init file just like you specified. it doesnt work. I attached my file.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2207
  • Hero Points: 275
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #5 on: March 26, 2014, 01:04:53 pm »
Try sending those commands explicitly to GDB after starting a session.  From the SlickEdit command line:

Code: [Select]
debug-send-command set print repeats 1000
Then step or continue to the next breakpoint so that it forces the watches to be read again.

If that doesn't work, it could be that the GDB/MI interface simply ignores these settings.

BTW, issuing a "continue" command in your .gdbinit is troublesome.  I wouldn't be surprised if that is causing delays attaching to GDB.

bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #6 on: March 26, 2014, 01:10:25 pm »
Without continue i cannot debug, because it says that gdb could not step into application.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2207
  • Hero Points: 275
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #7 on: March 26, 2014, 01:22:17 pm »
SlickEdit only issues an initial step-into when you start debugging by stepping in, so I'm guessing that you are trying to attach to a remote target by hacking the .gdbinit instead of using the Attach to Remote dialog.  So, if that works for you now, fine.  But, like any hack, don't expect it to always work.

bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #8 on: March 26, 2014, 01:34:09 pm »
Im not rly sure what are you talking about. I am using attach to remote process.

bremenpl

  • Community Member
  • Posts: 62
  • Hero Points: 0
  • microcontrollers <3
Re: Visual "optimalisation" of watched variables when debbuging
« Reply #9 on: March 28, 2014, 10:47:47 am »
Adding this command (debug-send-command set print repeats 1000) by hand didnt help... So could you please explain me is there anything that i am actually doing wrong and thats why this is happening? I got a bit lost.

EDIT: I would really aprichiate some futher help- unsigned char arrays show only 24 members in watch for me... Please. I have provided the print repeat command and it didnt help :/.