From: Daniel Jacobowitz <drow@mvista.com>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: fnf@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFC] const qualifiers in gdb.c++/method.exp
Date: Wed, 09 Jan 2002 10:52:00 -0000 [thread overview]
Message-ID: <20020109135311.A29859@nevyn.them.org> (raw)
In-Reply-To: <200201091652.KAA16574@duracef.shout.net>
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
next prev parent reply other threads:[~2002-01-09 18:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-09 8:53 Michael Elizabeth Chastain
2002-01-09 10:52 ` Daniel Jacobowitz [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-01-11 5:13 Michael Elizabeth Chastain
2002-01-10 7:07 Michael Elizabeth Chastain
2002-01-10 11:59 ` Daniel Jacobowitz
2002-01-08 9:47 Fred Fish
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020109135311.A29859@nevyn.them.org \
--to=drow@mvista.com \
--cc=fnf@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=mec@shout.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox