debug - plague of complaints continues

[Radek]

Okay, I am able to get variables in the watches window now.

(1) Complaint #1:

Code

class dvec
{
  double *data;
  int        size;
  ...
};

Is it possible to see the contents of data? I am able to see only the address. Clicking on the "raw data" button gives gives me only the address again. All choices in the context menu are grayed, both in the watches window and in the raw data window. No chance to see *data as an array of doubles. No chance, really?

Complaint #2:

Okay, dvec is not as stupid as it seems to be and it can use user supplied buffer as its data. This could provide the values, at least for now, because the array of doubles can be dereferenced. Tracing though the testing program again, something seems to be wrong. Tracing once more and more carefully:

Code

dvec rv;

...

bool bb = rv.alloc(5);

Returns true. Strange. Okay, I know the address of rv. Tracing into alloc(), this should be the same address but it is not, at least in the watches window. The dvec allocates correctly, sets its size but, on return, the size of rv is wrong in the watches window as well as the buffer address. Note: I have reloaded rv into the watches, so that it is not a problem of oudated data in the window.

Being completely desperate, I wrote a dump() routine:

Code

void dump( const dvec& vec )
{
  double *d = vec.data();

  printf("%5.1f  %5.1f  %5.1f  %5.1f  %5.1f\n",d[0],d[1],d[2],d[3],d[4]);
}

I inserted dump() into the code and traced again. The output is as expected and it is correct so that this is not a gdb problem. Aye, aye, what I am doing wrong now? Debian, Gnome, svn 7932.

[oBFusCATed]

1. This is limitation of the gdb/cli interface we are using, sorry. The only way to see the value is to add a separate watch
2. I'm not sure what is the question, be specific, please

[Radek]

(1) Watching "rv.data" works, thanks, but I don't see a limitation. If the user can watch "rv.data", why the debugger interface cannot? Adding objects and then object members in a watches or local variables windows seems to be a bit unfortunate.
(2) I made the dvec use a user supplied buffer. Then I watched the buffer but the values there did not change even if they should. Searching for a reason, I found a strange behavior or the address of the instance of dvec as well as the strange values of other class data items (the dvec size is an int but it is not shown correctly).

[oBFusCATed]

1. It will be too complex and too slow, it will be fixed in the new gdb/mi plugin, someday.
2. Still don't understand.

[Radek]

Code

#include <dvec.hpp>
#include <stdio.h>


int main()
{
  double dd1[] = { 0.0,  1.0, -2.0,  3.0, -4.0 };
  double dd2[] = { 1.0, -2.0,  3.0, -4.0,  5.0 };
  double dd3[] = { 0.0,  0.0,  0.0,  0.0,  0.0 };
  double dd;

  dvec     a,b,c;
  dvec::el e;
  bool     bb;

  bb = a.mkview(dd1,5);   // use dd1 for a data buffer of a, size = 5
  bb = b.mkview(dd2,5);   // use dd2 for a data buffer of b, size = 5
  bb = c.mkview(dd3,5);   // use dd3 for a data buffer of c, size = 5
  c  = a + b;

  ...

Debug and watch dd3. On the line c = a + b; dd3 should change, but it does not. When watching c.data, the c.data does change as expected. In the meantime, I have met the dreaded "incomplete type" - when I compiled the library as release. Even if the test program is compiled as debug and even if the header dvec.hpp is available, dvec is now "incomplete type" and "there is no member named c.data". Does it mean that I must use either debug compiled and unoptimized libraries or I cannot debug because I won't see any library-defined data? I understand that with a release build I cannot trace into the library (or I get the assembler window) but I should see the data described in headers. Is the gdb API so rudimental? Complaint #3  

[oBFusCATed]

The incomplete type is a gdb problem, if you're using gdb-7.4 and pretty new gdb you should report it in the gdb's bugzilla (probably first asking in the mailing list and searching the internet).

If you debug release builds all bets are of and the result can be pretty random.
Also if you don't provide the full source code I can't help you here...

[Radek]

gdb is 7.0.1. The sources of dvec are attached. The lib folder contains all needed sources and the dvec.hpp header. Add all this to a project and compile a static library. No additional libraries or settings of the project are needed. The code is a standard C99, no breaking news from C09 or C11 have been used. The main.cpp is the test program. Create another project, add the library and the header to the build options and compile.

As far as the "incomplete type" is concerned, it occurs only with the release build of the library, not with the debug build. And I don't see why the results should be so random: With a release build, you cannot trace through the library code, because you do not have any debug info and, usually, you do not have the source code. But you should see data structures, because you have the headers, which should be used in creating a debug build of the tested program. For example, the Open Watcom debugger allows you to see the data even with a release build of a library. This way, you can detect problems caused by the optimizer.

The "incomplete type" is rather annoying. Those that have debugged wxWidgets programs can tell ...

[attachment deleted by admin]

[oBFusCATed]

How can a c++ code be standard c99 code? Making the file extension to be .cpp means the code is C++!
And as I said first try gdb 7.4 before continuing.

And I don't see why the results should be so random

Because the gcc compiler is optimizing compiler and the most important goal for such compilers is speed not ease of debugging in release builds.
Also search the thread on the gcc mailing list about the discussion about improving the debugging in release builds (it happened in the 4.5,4.6,4.7 time frame).

Also I'm telling you this from experience, not speculating about how this is logical to be happening...