From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DB0D4386F001; Mon, 12 Oct 2020 17:12:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB0D4386F001 From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug c++/26550] Object of class with virtual base classes printed incorrectly (gdb.cp/ambiguous.exp) Date: Mon, 12 Oct 2020 17:12:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 17:12:28 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26550 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Pedro Alves : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D87a37e5e078f= 506fa9905b74e9238593c537fcd5 commit 87a37e5e078f506fa9905b74e9238593c537fcd5 Author: Pedro Alves Date: Fri Aug 28 21:10:59 2020 +0100 Reject ambiguous C++ field accesses (PR exp/26602) The gdb.cp/ambiguous.exp testcase had been disabled for many years, but recently it was re-enabled. However, it is failing everywhere. That is because it is testing an old feature that is gone from GDB. The testcase is expecting to see an ambiguous field warning, like: # X is derived from A1 and A2; both A1 and A2 have a member 'x' send_gdb "print x.x\n" gdb_expect { -re "warning: x ambiguous; using X::A2::x. Use a cast to disambiguate.\r\n\\$\[0-9\]* =3D \[-\]*\[0-9\]*\r\n$gdb_prompt $" { pass "print x.x" } -re "warning: x ambiguous; using X::A1::x. Use a cast to disambiguate.\r\n\\$\[0-9\]* =3D \[-\]*\[0-9\]*\r\n$gdb_prompt $" { pass "print x.x" } -re ".*$gdb_prompt $" { fail "print x.x" } timeout { fail "(timeout) print x.x" } } However, GDB just accesses one of the candidates without warning or error: print x.x $1 =3D 1431655296 (gdb) FAIL: gdb.cp/ambiguous.exp: print x.x (The weird number is because the testcase does not initialize the variables.) The testcase come in originally with the big HP merge: +Sun Jan 10 23:44:11 1999 David Taylor + + + The following files are part of the HP merge; some had longer + names at HP, but have been renamed to be no more than 14 + characters in length. Looking at the tree back then, we find that warning: /* Helper function used by value_struct_elt to recurse through baseclasses. Look for a field NAME in ARG1. Adjust the address of ARG1 by OFFSET bytes, and search in it assuming it has (class) type TYPE. If found, return value, else return NULL. If LOOKING_FOR_BASECLASS, then instead of looking for struct fields, look for a baseclass named NAME. */ static value_ptr search_struct_field (name, arg1, offset, type, looking_for_baseclass) char *name; register value_ptr arg1; int offset; register struct type *type; int looking_for_baseclass; { int found =3D 0; char found_class[1024]; value_ptr v; struct type *vbase =3D NULL; found_class[0] =3D '\000'; v =3D search_struct_field_aux (name, arg1, offset, type, looking_for_baseclass, &found, found_class, &vbase); if (found > 1) warning ("%s ambiguous; using %s::%s. Use a cast to disambiguate.", name, found_class, name); return v; } However, in current GDB, search_struct_field does not handle the ambiguous field case, nor is that warning found anywhere. Somehow it got lost over the years. That seems like a regression, because the compiler (as per language rules) rejects the ambiguous accesses as well. E.g.: gdb.cp/ambiguous.cc:98:5: error: request for member 'x' is ambiguous 98 | x.x =3D 1; | ^ gdb.cp/ambiguous.cc:10:7: note: candidates are: 'int A2::x' 10 | int x; | ^ gdb.cp/ambiguous.cc:4:7: note: 'int A1::x' 4 | int x; | ^ This patch restores the feature, though implemented differently and with better user experience, IMHO. An ambiguous access is now an error instead of a warning, and also GDB shows you all the candidates, like: (gdb) print x.x Request for member 'x' is ambiguous in type 'X'. Candidates are: 'int A1::x' (X -> A1) 'int A2::x' (X -> A2) (gdb) print j.x Request for member 'x' is ambiguous in type 'J'. Candidates are: 'int A1::x' (J -> K -> A1) 'int A1::x' (J -> L -> A1) Users can then fix their commands by casting or by specifying the baseclass explicitly, like: (gdb) p x.A1::x $1 =3D 1 (gdb) p x.A2::x $2 =3D 2 (gdb) p ((A1) x).x $3 =3D 1 (gdb) p ((A2) x).x $4 =3D 2 (gdb) p j.K::x $12 =3D 1 (gdb) p j.L::x $13 =3D 2 (gdb) p j.A1::x base class 'A1' is ambiguous in type 'J' The last error I've not touched; could be improved to also list the baseclass candidates. The showing the class "path" for each candidate was inspired by GCC's output when you try an ambiguous cast: gdb.cp/ambiguous.cc:161:8: error: ambiguous conversion from derived c= lass 'const JVA1' to base class 'const A1': class JVA1 -> class KV -> class A1 class JVA1 -> class A1 (A1) jva1; ^~~~ I did not include the "class" word as it seemed unnecessarily repetitive, but I can include it if people prefer it: (gdb) print j.x Request for member 'x' is ambiguous in type 'J'. Candidates are: 'int A1::x' (class J -> class K -> class A1) 'int A1::x' (class J -> class L -> class A1) The testcase is adjusted accordingly. I also took the chance to modernize it at the same time. Also, as mentioned above, the testcase doesn't currently initialize the tested variables. This patch inializes them all, giving each field a distinct value, so that we can be sure that GDB is accessing the right fields / offsets. The testcase is extended accordingly. Unfortunately, this exposes a bug, not addressed in this patch. The bug is around a class that inherits from A1 directly and also inherits from two other distinct base classes that inherit virtually from A1 in turn: print jva1.KV::x $51 =3D 1431665544 (gdb) FAIL: gdb.cp/ambiguous.exp: all fields: print jva1.KV::x print jva1.KV::y $52 =3D 21845 (gdb) FAIL: gdb.cp/ambiguous.exp: all fields: print jva1.KV::y (gdb) print /x (KV)jva1 $4 =3D { =3D , _vptr.KV =3D 0x555555557b88 , i =3D 0x457} (gdb) print /x (A1)(KV)jva1 Cannot access memory at address 0x0 Since that's an orthogonal issue, I filed PR c++/26550 and kfailed the tests that fail because of it. gdb/ChangeLog: PR exp/26602 * valops.c (struct struct_field_searcher): New. (update_search_result): Rename to ... (struct_field_searcher::update_result): ... this. Simplify prototype. Record all found fields. (do_search_struct_field): Rename to ... (struct_field_searcher::search): ... this. Simplify prototype. Maintain stack of visited baseclass path. Call update_result f= or fields too. Keep searching fields in baseclasses instead of stopping at the first found field. (search_struct_field): Use struct_field_searcher. When looking for fields, report ambiguous access attempts. gdb/testsuite/ChangeLog: PR exp/26602 PR c++/26550 * gdb.cp/ambiguous.cc (marker1): Delete. (main): Initialize all the fields of the locals. Replace marke= r1 call with a "set breakpoint here" marker. * gdb.cp/ambiguous.exp: Modernize. Use gdb_continue_to_breakpo= int instead of running to marker1. Add tests printing all the variables and all the fields of the variables. (test_ambiguous): New proc, expecting the new GDB output when a field access is ambiguous. Change all "warning: X ambiguous" tests to use it. --=20 You are receiving this mail because: You are on the CC list for the bug.=