Re: gdb, c++ & namespaces

Re: gdb, c++ & namespaces

[Michael Elizabeth Chastain]

eli> The manual doesn't mention "static type" and "dynamic type" in the
eli> section that describes "set pruint".  I think it should, if this
eli> terminology is to be widely accepted.

I don't know what the popular usage in the C++ community is.
I don't want to invent new phrases if there are existing phrases.

I checked "The C++ Programming Language" and it does not have
any nice phrases to distinguish "the type that the pointer says"
versus "the type that the object in memory has".

Michael C

Re: gdb, c++ & namespaces

[Marcel Lanz]

If I think of a "the type that the pointer says" in C++ this is a
pointer of type A pointing to something which is not of type A; hence
its casted to another type or its a pointer to a derived class.

"the type that the object in memory has" is a pointer of type A that
points to an object of type A.

I would say, that polymorphism is like casting type A to B if you can be
sure that all invariants are valid if you use the object after the cast.
With dynamic_cast<B*>(a); you can cast a polymorphic object in a safe
manner on runtime.

This way, I would say that a "dynamic type" is a polymorphic type.
A "static type" is a non-polymorphic type.

void* in C is a very havy polymorphic type but not safe.
C++'s aim was to avoid the void* and make type casting safe.

So if we discuss about "dynamic type" and "static type" for the
debugger, its perhaps not a good idea to use C++ known names for it,
because "a pointer of type A which points in a unsafe manner to something of type B"
is not in the spirit of C++.

What about "pointer type" and "object type" ?
 
Marcel

On Thu, Jan 15, 2004 at 07:51:12AM -0500, Michael Elizabeth Chastain wrote:
> eli> The manual doesn't mention "static type" and "dynamic type" in the
> eli> section that describes "set pruint".  I think it should, if thi
> eli> terminology is to be widely accepted.
> 
> I don't know what the popular usage in the C++ community is.
> I don't want to invent new phrases if there are existing phrases.
> 
> I checked "The C++ Programming Language" and it does not have
> any nice phrases to distinguish "the type that the pointer says"
> versus "the type that the object in memory has".
> 
> Michael C

-- 
Marcel Lanz
http://www.ds9.ch/lanz/
marcel.lanz@ds9.ch | marcel.lanz@n-1.ch
GnuPG: F975 C6F7 04C8 642B 6DF4  4DF4 2945 F02A 797E 7DAB

Re: gdb, c++ & namespaces

[Robert Zeh]

Michael Elizabeth Chastain wrote:

>eli> The manual doesn't mention "static type" and "dynamic type" in the
>eli> section that describes "set pruint".  I think it should, if this
>eli> terminology is to be widely accepted.
>
>I don't know what the popular usage in the C++ community is.
>I don't want to invent new phrases if there are existing phrases.
>
>I checked "The C++ Programming Language" and it does not have
>any nice phrases to distinguish "the type that the pointer says"
>versus "the type that the object in memory has".
>
>Michael C
>
>  
>
I believe "static type" and "dynamic type" are the correct phrases to 
use.  They correspond nicely to C++'s static_cast and dynamic_cast 
operators.  They also match Stroustrup's discussion in section 24.2.3 of 
"The C++ Programming Language" (3rd edition).  He refers to the runtime 
types as the dynamic type, and type known at compile time as the static 
type.

Robert Zeh

Re: gdb, c++ & namespaces

[Gabriel Dos Reis]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

| eli> The manual doesn't mention "static type" and "dynamic type" in the
| eli> section that describes "set pruint".  I think it should, if this
| eli> terminology is to be widely accepted.
| 
| I don't know what the popular usage in the C++ community is.
| I don't want to invent new phrases if there are existing phrases.

"static type" and "dynamic type" are not new phrases :-)

| I checked "The C++ Programming Language" and it does not have
| any nice phrases to distinguish "the type that the pointer says"
| versus "the type that the object in memory has".

I think GDB maintainers should also consult the C++ standard when they
implement support tools for C+ ;-).

   1.3.3 dynamic type
   the type of the most derived object (1.8) to which the lvalue
   denoted by an lvalue expression refers. [Example: if a pointer
   (8.3.1) p whose static type is "pointer to class B" is pointing to
   an object of class D, derived from B (clause 10), the dynamic type
   of the expression *p is "D".  References (8.3.2) are treated
   similarly. ]  The dynamic type of an rvalue is its static type.


   1.3.11 static type
   the type of an expression (3.9), which type results from analysis
   of the program without considering execution semantics. The static
   type of an expression depends only on the form of the program in
   which the expression appears, and does not change while the program
   is executing.  

-- Gaby

Re: gdb, c++ & namespaces

[Michael Elizabeth Chastain]

Hi Marcel,

The two debugging formats are: dwarf-2 and stabs+ (not dwarf and stabs).
dwarf-2 is supported much better than stabs+ now, so try building
your program with -gdwarf-2.

> (netsilicon-gdb) print *dp
> warning: can't find class named `tnos::net::DatagramPacket', as given by
> C++ RTTI
> $2 = {_vptr.DatagramPacket = 0xeffb0, ia = 0x206548, isa = 0x206690,
> buffer = 0x206558 "", bufferLength = 0xff, length = 0xff}

Try playing with the "set print object" flag:

  (gdb) set print object off
  (gdb) print *dp
  (gdb) set print object on
  (gdb) print *dp

When "set print object" is off, gdb will print an object of the type
of the pointer (we call this the "static type").  When "set print object"
is on, gdb will print the type of the object in memory (we call this
the "dynamic type".

That warning is sometimes harmless if the data fields are what you
expect.  Are they?

Michael C
GDB QA Guy

Re: gdb, c++ & namespaces

[Marcel Lanz]

Hi Michael

> That warning is sometimes harmless if the data fields are what you
> expect.  Are they?

(netsilicon-gdb) print *dp->isa
warning: can't find class named `tnos::net::DatagramPacket', as given by C++ RTTI
warning: can't find class named `tnos::net::DatagramPacket', as given by C++ RTTI
warning: can't find class named `tnos::net::DatagramPacket', as given by C++ RTTI
warning: can't find class named `tnos::net::InetSocketAddress', as given by C++ RTTI
$5 = warning: can't find class named `tnos::net::InetSocketAddress', as given by C++ RTTI
{_vptr.InetSocketAddress = 0xeff78, port = 0x8094, inetAddress =
0x2066a0}

Yes. they do. DDD told me, that he wouldn't like to display the object:
Disabling display 2 to avoid infinite recursion

In the console, I see the fields, beside the warning. so it seems that
ist usable for me.

Best regards
Marcel

Re: gdb, c++ & namespaces

[Eli Zaretskii]

> Date: Wed, 14 Jan 2004 09:17:30 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
>   (gdb) set print object off
>   (gdb) print *dp
>   (gdb) set print object on
>   (gdb) print *dp
> 
> When "set print object" is off, gdb will print an object of the type
> of the pointer (we call this the "static type").  When "set print object"
> is on, gdb will print the type of the object in memory (we call this
> the "dynamic type".

The manual doesn't mention "static type" and "dynamic type" in the
section that describes "set pruint".  I think it should, if this
terminology is to be widely accepted.

Re: gdb, c++ & namespaces

[Gabriel Dos Reis]

"Eli Zaretskii" <eliz@elta.co.il> writes:

| > Date: Wed, 14 Jan 2004 09:17:30 -0500 (EST)
| > From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
| > 
| >   (gdb) set print object off
| >   (gdb) print *dp
| >   (gdb) set print object on
| >   (gdb) print *dp
| > 
| > When "set print object" is off, gdb will print an object of the type
| > of the pointer (we call this the "static type").  When "set print object"
| > is on, gdb will print the type of the object in memory (we call this
| > the "dynamic type".
| 
| The manual doesn't mention "static type" and "dynamic type" in the
| section that describes "set pruint".  I think it should, if this
| terminology is to be widely accepted.

The phrases "static type" and "dynamic type" are standard terms with
precise meanings used to describe Standard C++.  
"static type" is the type of the expression, as  determined by static
analysis (i.e. at compile-time) to access and object.
"dynamic type" is what the C standard would call the "effective type".
It is the type of the object as determined at its construction/creation.  
See the first chapter of the C++ standard.

-- Gaby

Re: gdb, c++ & namespaces

[Michael Elizabeth Chastain]

> But It would be interesting to me to know why it fails ? just a line.

Honestly, we have so much work to do for gdb 6.0 and gdb 6.1,
it's unlikely that anyone will want to diagnose a problem with
gdb 5.2.1.  So you might get a response to this, but don't be
surprised if you don't.

Michael C
GDB QA Guy

Re: gdb, c++ & namespaces

[Marcel Lanz]

Thank you. It seems the worth to rebuild my debugger.

On Wed, Jan 14, 2004 at 07:02:13AM -0500, Michael Elizabeth Chastain wrote:
> > But It would be interesting to me to know why it fails ? just a line.
> 
> Honestly, we have so much work to do for gdb 6.0 and gdb 6.1,
> it's unlikely that anyone will want to diagnose a problem with
> gdb 5.2.1.  So you might get a response to this, but don't be
> surprised if you don't.
> 
> Michael C
> GDB QA Guy

Re: gdb, c++ & namespaces

[Marcel Lanz]

I have gdb-6.0 now. same compiler.

dp is a pointer to a instance like:

DatagramPacket* dp;

on the prompt I do:

(netsilicon-gdb) print *dp
warning: can't find class named `tnos::net::DatagramPacket', as given by
C++ RTTI
$2 = {_vptr.DatagramPacket = 0xeffb0, ia = 0x206548, isa = 0x206690,
buffer = 0x206558 "", bufferLength = 0xff, length = 0xff}

tnos::net::DatagramPacket is a class in the namespace tnos::net

any ideas ?

I've read about two debug formats: stabs and dwarf. In the manual of Mr.
Stallman, stabs is recommended "for best results" with c++.

regards Marcel

On Wed, Jan 14, 2004 at 07:02:13AM -0500, Michael Elizabeth Chastain wrote:
> > But It would be interesting to me to know why it fails ? just a line.
> 
> Honestly, we have so much work to do for gdb 6.0 and gdb 6.1,
> it's unlikely that anyone will want to diagnose a problem with
> gdb 5.2.1.  So you might get a response to this, but don't be
> surprised if you don't.
> 
> Michael C
> GDB QA Guy

-- 
Marcel Lanz
http://www.ds9.ch/lanz/
marcel.lanz@ds9.ch | marcel.lanz@n-1.ch
GnuPG: F975 C6F7 04C8 642B 6DF4  4DF4 2945 F02A 797E 7DAB

Re: gdb, c++ & namespaces

[Daniel Jacobowitz]

On Wed, Jan 14, 2004 at 02:49:20PM +0100, Marcel Lanz wrote:
> I have gdb-6.0 now. same compiler.
> 
> dp is a pointer to a instance like:
> 
> DatagramPacket* dp;
> 
> on the prompt I do:
> 
> (netsilicon-gdb) print *dp
> warning: can't find class named `tnos::net::DatagramPacket', as given by
> C++ RTTI
> $2 = {_vptr.DatagramPacket = 0xeffb0, ia = 0x206548, isa = 0x206690,
> buffer = 0x206558 "", bufferLength = 0xff, length = 0xff}
> 
> tnos::net::DatagramPacket is a class in the namespace tnos::net
> 
> any ideas ?

Namespace support is still being developed.  If you build GDB from CVS
you will probably have better results, but it isn't finished.

> I've read about two debug formats: stabs and dwarf. In the manual of Mr.
> Stallman, stabs is recommended "for best results" with c++.

That is out of date and inaccurate.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb, c++ & namespaces

[Andrew Cagney]

> I've read about two debug formats: stabs and dwarf. In the manual of Mr.
> Stallman, stabs is recommended "for best results" with c++.

Hmm, bug.  Which manual?

Andrew

Re: gdb, c++ & namespaces

[Marcel Lanz]

On Wed, Jan 14, 2004 at 10:29:42AM -0500, Andrew Cagney wrote:
> >I've read about two debug formats: stabs and dwarf. In the manual of Mr.
> >Stallman, stabs is recommended "for best results" with c++.
> 
> Hmm, bug.  Which manual?

section 10.4.1 in "Debugging with GDB: The GNU Source-Level Debuger" for
GDB Version 5.1.1. I have the book here.

Re: gdb, c++ & namespaces

[Andrew Cagney]

> On Wed, Jan 14, 2004 at 10:29:42AM -0500, Andrew Cagney wrote:
> 
>> >I've read about two debug formats: stabs and dwarf. In the manual of Mr.
>> >Stallman, stabs is recommended "for best results" with c++.
> 
>> 
>> Hmm, bug.  Which manual?
> 
> 
> section 10.4.1 in "Debugging with GDB: The GNU Source-Level Debuger" for
> GDB Version 5.1.1. I have the book here.

Ah, thanks.  It now reads:

For best results when using @sc{gnu} C@t{++}, use the DWARF 2 debugging
format; if it doesn't work on your system, try the stabs+ debugging
format.  You can select those formats explicitly with the @code{g++}
command-line options @option{-gdwarf-2} and @option{-gstabs+}.
@xref{Debugging Options,,Options for Debugging Your Program or @sc{gnu}
CC, gcc.info, Using @sc{gnu} CC}.

The latest manuals are online.  See:
http://www.gnu.org/software/gdb/documentation/

Andrew

Re: gdb, c++ & namespaces

[Michael Elizabeth Chastain]

Hi Marcel,

You have an old version of gdb.  The current version is gdb 6.0.
There has been a lot of C++ work done in gdb 5.3 and gdb 6.0,
so please try gdb 6.0 first.

Michael C

Re: gdb, c++ & namespaces

[Marcel Lanz]

OK. good point.

But It would be interesting to me to know why it fails ? just a line.

I have to build my compilers and environment by myself for my arm dev
environment, so I hope its not just "try the newer version..."

thank you. marcel

On Wed, Jan 14, 2004 at 06:36:05AM -0500, Michael Elizabeth Chastain wrote:
> Hi Marcel,
> 
> You have an old version of gdb.  The current version is gdb 6.0.
> There has been a lot of C++ work done in gdb 5.3 and gdb 6.0,
> so please try gdb 6.0 first.
> 
> Michael C

gdb, c++ & namespaces

[Marcel Lanz]

I have a C++ program using namespaces.
If I try to display a pointer to an instance like

sys::net::UDPSocket* s;

I get the following error from gdb (trough ddd):

can't find class named sys::net::UDPSocket, as given by C++ RTTI

If I have a reference to such an instance. No problem.
I use -g to compile with debug information.


Is there a limitation for namespace support in gdb, g++ ?

-V outputs:
GNU gdb 5.2.1
gcc version 3.3.1
ddd 3.3.1

-- 
Marcel Lanz
http://www.ds9.ch/lanz/
marcel.lanz@ds9.ch | marcel.lanz@n-1.ch
GnuPG: F975 C6F7 04C8 642B 6DF4  4DF4 2945 F02A 797E 7DAB