ANNOUNCE: KDevelop 1.1final released

[Daniel Berlin]

>>>>> "jbb" ==   <jbb at ihug.co.nz> writes:

   >> KD1.1 Bug report

   >> 2. Debugger cannot see non-class data defined in the namespace.

   | Do you mean
   | namespace foo {   int bar; };  and you cannot see bar?
   | I can't get gdb to show that either.
   | (gdb) print foo::bar
   | No symbol "foo" in current context.

   jbb> or any variations thereof. The only way I've found so far is to look
   jbb> at dissembled code then add *(int*)0x"address of bar" to the
   jbb> watch. There must be a simpler way...


There is.
Single quote it.
for this program:
#include <iostream.h> 
namespace foo { int bar=5;} int main(int argc, char **argv) { cout<<foo::bar<<endl;}

Look:
(gdb) r
Starting program: /usr/src/a.out

Breakpoint 1, main () at e.cc:9
9               cout <<foo::bar<<endl;
(gdb) p foo::bar
No symbol "foo" in current context.
(gdb) p 'foo::bar'
$1 = 5
(gdb)



   >> From scanning the gdb mailing list, Daniel Berlin writes (on a related
   >> problem)
   jbb> "Assuming mangling and everything is working fine, namespaces should
   jbb> have no problem.  If they do, i'll make them have no problems.  :)"

   | Hi Daniel :-)
   | how should/does this work?

This actually isn't a bug, afaik.
It's just like how if you don't single quote, you won't get proper completion 
of class methods/variables (IE you have to type 'fred::<TAB> rather than
fred::<TAB>).
If you say foo::bar, without the quotes, it assumes you mean an class named
foo, field bar.
It doesn't get into the actual expression parsing code:
(gdb) set expressiondebug 10000
(gdb) p foo::bar
No symbol "foo" in current context.
(gdb)
No symbol "foo" in current context.
(gdb) p 'foo::bar'
Dump of expression @ 0x81b3780, before conversion to prefix form:
Expression: `foo::bar'
        Language c++, 4 elements, 12 bytes each.
        Index                Opcode         Hex Value  String Value
            0          OP_VAR_VALUE  577737328252944429  -...........
            1               OP_NULL  577737328252944384  ............
            2   <unknown 136595940>  577737328389540324  .I$.........
            3          OP_VAR_VALUE  577737328252944429  -...........
Dump of expression @ 0x81b3780, after conversion to prefix form:
Expression: `foo::bar'
        Language c++, 4 elements, 12 bytes each.


            0  OP_VAR_VALUE          Block @0x0, symbol @0x82449e4 (_3foo$bar)
$2 = 5
(gdb)

It would, however work, if you were dealing with a static member of a class.
Why is it so convoluted?
Because none of the debug info formats have no built-in support for namespaces.
DWARF-2 will very soon now (It's been discussed by the new DWARF-2 committee, 
and is an official issue), and is, in general, a *much* better debugging
info format, but i don't believe it's the default on Linux yet. Should be
soon, IIRC (You won't notice except things will just work better).

Because they have no built in support for namespaces, when you print
foo::bar, it looks for foo as an object.
But because namespaces aren't objects in the debug info, foo as an object
doesn't exist.
when you print 'foo::bar', it mangles it, and then looks for it. And low and
behold, _3foo$bar really does exist, so it prints the value.

Get it?


   >> 3. Debugger lack to show data references values but show only it
   >> address.  There is no problem by manual adding. Showing address of
   >> reference type data before value is not so good because there is a
   >> screen space problem.
   jbb> Not sure I understand. Can you give example code, what is displayed,
   jbb> and the way you'd prefer to see it.

   >> 4. Debugger If I add pointer data in the watch I have no way to see any
   >> pointed data by mouse clicking. In case ADB* ptr; I have to add only
   >> ptr[0] or *ptr.
   jbb> Looks like a bug. You'll have to use your suggested workaround in the
   jbb> meantime.
Not a GDB bug, of course.
:)


   | -- 
   | Regards,
   | 
   | jbb
   | http://homepages.ihug.co.nz/~jbb
   | ICQ: 60412209