From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113382 invoked by alias); 3 Mar 2015 10:02:58 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 113300 invoked by uid 48); 3 Mar 2015 10:02:53 -0000 From: "derodat at adacore dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/53927] wrong value for DW_AT_static_link Date: Tue, 03 Mar 2015 10:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 4.6.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: derodat at adacore dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.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://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg00274.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53927 --- Comment #17 from Pierre-Marie de Rodat --- (In reply to Tom Tromey from comment #16) > I'm curious if you tried it on the test case in this PR. I did not, but it looks like it now works as expected. Here are the frame b= ase info for "nestee" and the static link info for "nested": [nestee] <69> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_c= fa) [nested] DW_AT_static_link : 6 byte block: 91 60 6 23 20 6 (DW_OP_fbre= g: -32; DW_OP_deref; DW_OP_plus_uconst: 32; DW_OP_deref) ... and the CFA for the two locations we will be interrested in later: LOC CFA 0000000000400496 rsp+8 0000000000400497 rsp+16 000000000040049a rbp+16 # A 00000000004004af rsp+8 LOC CFA 000000000040053b rsp+8 000000000040053c rsp+16 000000000040053f rbp+16 # B 0000000000400564 rsp+8 Now in GDB: $ gdb -n -q -ex 'b pr53927.c:7' -ex r --args ./pr53927 [...] Breakpoint 1, nested (nested_arg=3D10) at pr53927.c:7 7 return nested_arg + 23 + self_call; /* Break here */ (gdb) bt #0 nested (nested_arg=3D10) at pr53927.c:7 #1 0x000000000040052b in nestee (computer=3D0x7fffffffdf24, arg=3D10) = at pr53927.c:13 #2 0x000000000040051d in nestee (computer=3D0x40052d , arg=3D5) = at pr53927.c:11 #3 0x000000000040055e in main (argc=3D1, argv=3D0x7fffffffe058) at pr53927.c:23 (gdb) p $pc $1 =3D (void (*)()) 0x4004a4 # This PC corresponds to the "B" line above: CFA =3D $rbp + 16 (gdb) x/1gx $rbp + 16 - 32 0x7fffffffdea0: 0x00007fffffffdf20 (gdb) x/1gx 0x00007fffffffdf20 + 32 0x7fffffffdf40: 0x00007fffffffdf60 ... so the static link expression gives us the following frame base address: 0x00007fffffffdf60 (gdb) f 2 #2 0x000000000040051d in nestee (computer=3D0x40052d , arg=3D5) = at pr53927.c:11 11 arg =3D nestee (nested, arg + 5, 0); # This PC corresponds to the "A" line above: CFA =3D $rbp + 16 (gdb) p/x $rbp + 16 $2 =3D 0x7fffffffdf60 So the static link expression correctly yields the frame 2's=C2=A0CFA. > Yeah, growing these is to be avoided. > My patch for this added a method to symbol_computed_ops instead. >=20 > Unfortunately gitorious is acting weird so you can't see the patch > online :-(. But you can fetch from > https://gitorious.org/binutils-gdb/gdb.git > and look at the branch static-link-fix if you like. Interesting! Having a look at this: thank you! I=C2=A0guess you waited for = the GCC issue to be solved before submitting them to GDB? >>From gcc-bugs-return-479131-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 03 10:08:53 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 122878 invoked by alias); 3 Mar 2015 10:08:52 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 122858 invoked by uid 48); 3 Mar 2015 10:08:48 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/65291] protected using constructor default arguments not recognized Date: Tue, 03 Mar 2015 10:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg00275.txt.bz2 Content-length: 971 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65291 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Do you really need to attach a tarball with four separate files to demonstrate this?! It just makes it a pain to inspect the code. Here's the complete source: class A { public: A(int a = 0) { } }; class B : public A { public: B(int b1, int b2) : A(b1) {} protected: using A::A; }; class C : public B { C() : B() {} }; int main() { B b(1,2); C c; } The C++ standard says that B inherits a constructor taking a single int, the default argument is not inherited, so B has no default constructor, and G++ is correct to reject the program.