From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1B6843858D35; Fri, 31 Jul 2020 22:46:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B6843858D35 From: "moinakb001 at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/26326] New: C++ trivial destructor support when calling function from GDB Date: Fri, 31 Jul 2020 22:46:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: 9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: moinakb001 at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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: Fri, 31 Jul 2020 22:46:43 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26326 Bug ID: 26326 Summary: C++ trivial destructor support when calling function from GDB Product: gdb Version: 9.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: moinakb001 at gmail dot com Target Milestone: --- This problem is fundamentally one of small struct optimization and its interaction with C++. The fundamental problem here is that GDB doesn't recognize that C++ trivially destructible classes can become POD (Plain Old Data, C structs - this applies to C as well as C++), which in turn can be reclassified as INTEGER instead of MEMORY when the data is small enough (16= B, size of 2 x86_64 registers). We can prove this with the following C++ code: struct small_struct{ long long x[2]; }; struct small_struct small_test(int a){ struct small_struct s{{a}}; return s; } struct large_struct{ long long x[3]; }; struct large_struct large_test(int a){ struct large_struct s{{a}}; return s; } class class_without_destructor{ private: int x; public: class_without_destructor(int z): x(z){} ~class_without_destructor() =3D default; }; class_without_destructor test_trivial_destructor(int p){ class_without_destructor ret(p); return ret; } class class_with_destructor{ private: int x; public: class_with_destructor(int z): x(z){} ~class_with_destructor(){} }; class_with_destructor test_nontrivial_destructor(int p){ class_with_destructor ret(p); return ret; } GDB has no trouble recognizing in small_test that it shouldn't pass anything through rdi as the function will return values through rax and rdx, and it recognizes as well that it does have to pass in a memory location through r= di in large_test and in test_nontrivial_destructor: (gdb) p/x small_test(1) $1 =3D {x =3D {0x1, 0x0}} (gdb) p/x large_test(2) $2 =3D {x =3D {0x2, 0x0, 0x0}} (gdb) p/x test_nontrivial_destructor(3) $3 =3D {x =3D 0x3} However, GDB does not work correctly with test_trivial_destructor. It thinks that the program uses rdi values that it passes in to the function for stor= age and thus shows the stale value from the previous test: (gdb) p/x test_trivial_destructor(4) $4 =3D {x =3D 0x3} Relevant registers: rsi 0x4 4 rdi 0x7ffffffedeb0 140737488281264 It shifts the argument, and passes the first argument in rsi, just as it do= es in the nontrivial destructor case. This is because if doesn't recognize the following C++ behavior regarding trivial destructors, and expects that the values are passed back in memory through rdi. I'm not sure where the problem is, but it seems related to https://sourceware.org/bugzilla/show_bug.cgi?id=3D25054 --=20 You are receiving this mail because: You are on the CC list for the bug.=