From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29429 invoked by alias); 9 Jan 2002 18:52:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29388 invoked from network); 9 Jan 2002 18:52:33 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 9 Jan 2002 18:52:33 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16ONqZ-0007yJ-00; Wed, 09 Jan 2002 13:53:11 -0500 Date: Wed, 09 Jan 2002 10:52:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: fnf@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] const qualifiers in gdb.c++/method.exp Message-ID: <20020109135311.A29859@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , fnf@redhat.com, gdb-patches@sources.redhat.com References: <200201091652.KAA16574@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201091652.KAA16574@duracef.shout.net> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00187.txt.bz2 First of all, as best as I can tell, GCC simply doesn't support the stabs extensions for const and volatile. Rather than accepting this, we should detect it and mark them XFAILS. I would prefer to XFAIL based on debug info type and compiler rather than on result - if we lose the DWARF-2 const tag in a bug some day, it should start FAILing, not XFAILing! On Wed, Jan 09, 2002 at 10:52:52AM -0600, Michael Elizabeth Chastain wrote: > In _The C++ Programming Language_, Stroustrop, 3rd edition, > section 10.2.7 ("Self-Reference") talks about the type of "this": > > In a nonstatic member function, the keyword _this_ is a pointer to the > object for which the function was invoked. In a non-_const_ member > function of class _X_, the type of _this_ is _X*_. However, _this_ > is not an ordinary variable; it is not possible to take the address of > _this_ or to assign to _this_. In a _const_ member function of class > _X_, the type of _this_ is _const X*_ to prevent modification of the > object itself (see also S5.4.1). Note that he describes it as X *, not as X * const. I'm not convinced that GCC is within its rights to emit the latter const. However, it always seems to, at least as far back as 2.95. Optional is fine by me for these. > The next fragment deals with A::bar, which is a const method. By the book, > the type of "this" is "const A *". This means that "this" points to a > object which cannot be modified. Additionally, the "this" pointer itself > cannot be changed, so it is also okay if the type of "this" to be > "const A * const". > > Here are the actual types: > > "A *" > native i686-pc-linux-gnu, gcc 2.95.3, -gstabs+ > native i686-pc-linux-gnu, gcc 3.0.2, -gstabs+ > native i686-pc-linux-gnu, gcc HEAD, -gstabs+ > native i686-pc-linux-gnu, gcc gcc-3_0-branch, -gstabs+ Stabs vs. const as above. > "A * const" > native i686-pc-linux-gnu, gcc 3.0.2, -gdwarf-2 > native i686-pc-linux-gnu, gcc HEAD, -gdwarf-2 > native i686-pc-linux-gnu, gcc gcc-3_0-branch, -gdwarf-2 > > "const A * const" > native i686-pc-linux-gnu, gcc 2.95.3, -gdwarf-2 > > The first seven of these are wrong. The type needs to have a "const A *" > in it, rather than an "A *". That we lost this const is very interesting. It is present in the dwarf-2 information without a doubt. What version of GDB are you actually using to test this? (gdb) p this $1 = (const A * const) 0x4000ab40 That's 3_0-branch, -gdwarf-2. > Fragment 3: > > @@ -203,7 +203,7 @@ gdb_expect { > > send_gdb "print this\n" > gdb_expect { > - -re "\\$\[0-9\]* = \\(funk \\*\\) $hex\r\n$gdb_prompt $" { > + -re "\\$\[0-9\]* = \\(funk \\*( const)?\\) $hex\r\n$gdb_prompt $" { > pass "print this in getFunky" > } > -re ".*$gdb_prompt $" { fail "print this in getfunky" } > > This is fine. My stabs+ logs show a type of "funk *", my dwarf-2 > logs show a type of "funk * const", and either type is acceptable. > > === > > Fragment 4 > > @@ -226,7 +226,7 @@ gdb_expect { > > send_gdb "ptype A\n" > gdb_expect { > - -re "type = class A \{\r\n\[ \]*public:\r\n\[ \]*int x;\r\n\[ \]*int y;\r\n\r\n\[ \]*A & operator=\\(A const ?&\\);\r\n\[ \]*A\\(A const ?&\\);\r\n\[ \]*A\\((void|)\\);\r\n\[ \]*int foo\\(int\\);\r\n\[ \]*int bar\\(int\\) const;\r\n\[ \]*int baz\\(int, char\\) volatile;\r\n\[ \]*int qux\\(int, float\\) (const volatile|volatile const);\r\n\}\r\n$gdb_prompt $" { > + -re "type = class A \{\r\n\[ \]*public:\r\n\[ \]*int x;\r\n\[ \]*int y;\r\n\r\n\[ \]*A & operator=\\(A const ?&\\);\r\n\[ \]*A\\((A const|const A) ?&\\);\r\n\[ \]*A\\((void|)\\);\r\n\[ \]*int foo\\(int\\);\r\n\[ \]*int bar\\(int\\) const;\r\n\[ \]*int baz\\(int, char\\) volatile;\r\n\[ \]*int qux\\(int, float\\) (const volatile|volatile const);\r\n\}\r\n$gdb_prompt $" { > pass "ptype A" > } > -re "type = class A \{\r\n\[ \]*public:\r\n\[ \]*int x;\r\n\[ \]*int y;\r\n\r\n\[ \]*int foo\\(int\\);\r\n\[ \]*int bar\\(int\\) const;\r\n\[ \]*int baz\\(int, char\\);\r\n\[ \]*int qux\\(int, float\\) const;\r\n\}\r\n$gdb_prompt $" { > > Hmmm, yeah, this is fine. "A const &" and "const A &" mean the same thing > so gdb is okay if it emits either one. Yeah, this is just the change in demangler version. This'll come up again in a few more patches. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer