From owner-freebsd-toolchain@freebsd.org Thu May 11 01:34:39 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56630D670C1 for ; Thu, 11 May 2017 01:34:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B8CA1994 for ; Thu, 11 May 2017 01:34:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4B1YcT9060771 for ; Thu, 11 May 2017 01:34:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such Date: Thu, 11 May 2017 01:34:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org 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: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 01:34:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #10 from Mark Millard --- (In reply to John Baldwin from comment #8) The bt that I included shows libstdc++ in use inside /usr/local/bin/gdb, not libc++ . This is because /usr/local/bin/gdb was built under a gcc 4.2.1 world via the gcc 4.2.1 compiler (no clang present at the time). # ldd /usr/local/bin/gdb /usr/local/bin/gdb: libreadline.so.6 =3D> /usr/local/lib/libreadline.so.6 (0x42ba4000) libncurses.so.8 =3D> /lib/libncurses.so.8 (0x42bfc000) libkvm.so.7 =3D> /lib/libkvm.so.7 (0x42c55000) libutil.so.9 =3D> /lib/libutil.so.9 (0x42c77000) libthr.so.3 =3D> /lib/libthr.so.3 (0x42c9b000) libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x42cd6000) libm.so.5 =3D> /lib/libm.so.5 (0x42cf1000) libpython2.7.so.1 =3D> /usr/local/lib/libpython2.7.so.1 (0x42d28000) libexpat.so.1 =3D> /usr/local/lib/libexpat.so.1 (0x42f12000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x42f4b000) libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x42f83000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x43095000) libc.so.7 =3D> /lib/libc.so.7 (0x430b5000) libelf.so.2 =3D> /lib/libelf.so.2 (0x4325a000) (Avoiding delete-old-libs keeps libraries around that otherwise would not exist when I context switch. gcc-4.2.1-based and clang-based are based on the same /usr/src built two ways.) /usr/local/bin/gdb does use C++ exceptions internally, at least for some things. It is the original a.out that has clang-based bindings (libcxxrt.so.1 and libc++.so.1): # ldd ~/c_tests/a.out /root/c_tests/a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x4183b000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x4191e000) libm.so.5 =3D> /lib/libm.so.5 (0x41949000) libc.so.7 =3D> /lib/libc.so.7 (0x41980000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x41b33000) FYI: # ldd /usr/libexec/gdb=20 /usr/libexec/gdb: libm.so.5 =3D> /lib/libm.so.5 (0x41afa000) libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x41b31000) libgnuregex.so.5 =3D> /usr/lib/libgnuregex.so.5 (0x41b96000) libc.so.7 =3D> /lib/libc.so.7 (0x41bba000) (So fewer dependencies to have working well for it to be "working". No C++ library use.) As for #13, *info, and *lmo: #13 0x019b42b8 in solib_svr4_r_map (info=3D0x44002084) at solib-svr4.c:913 #14 0x019b4648 in svr4_current_sos_direct (info=3D0x436232c0) at solib-svr4.c:1494 #14 has the right address for info. #13 is reporting the R30 value as the info address for some reason (R30 is frequently used for PIC support in powerpc land). svr4_current_sos_direct passes its info value to solib_svr4_r_map unchanged. (gdb) up 14 #14 0x019b4648 in svr4_current_sos_direct (info=3D0x436232c0) at solib-svr4.c:1494 1494 lm =3D solib_svr4_r_map (info); Current language: auto; currently c++ (gdb) print *info $1 =3D {debug_base =3D 4, debug_loader_offset_p =3D 0, debug_loader_offset = =3D 0, debug_loader_name =3D 0x0, main_lm_addr =3D 0, interp_text_sect_low =3D 0, interp_text_sect_high =3D 0, interp_plt_sect_low =3D 0,=20 interp_plt_sect_high =3D 0, using_xfer =3D 0, probes_table =3D 0x0, solib= _list =3D 0x0} (gdb) down #13 0x019b42b8 in solib_svr4_r_map (info=3D0x44002084) at solib-svr4.c:913 913 ptr_type); (gdb) print *lmo $2 =3D {r_version_offset =3D 0, r_version_size =3D 4, r_map_offset =3D 4, r= _brk_offset =3D 8, r_ldsomap_offset =3D 20, link_map_size =3D 20, l_addr_offset =3D 0, = l_ld_offset =3D 8, l_next_offset =3D 12,=20 l_prev_offset =3D 16, l_name_offset =3D 4} This is via /usr/libexec/gdb on the same system build that a.out was produced and tested on (clang based). Other notes: /usr/local/bin/gdb segmentation faults looking at its own core file, much like it does looking at the a.out core file. I will note that in comment #3's list of differences it was /usr/libexec/gdb that got things like the rates for interrupts correct. (Both gdb's listed the same counts --but got very different rates. /usr/local/bin/gdb showed to rates that were too large by a lot.) Similar points go for other parts of the diff: /usr/libexec/gdb got more correct. This was a gcc 4.2.1 based environment, not clang-based. --=20 You are receiving this mail because: You are the assignee for the bug.=