Date: Thu, 11 May 2017 01:34:39 +0000 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 Message-ID: <bug-219153-29464-RRbYooPjK2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219153-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-219153-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219153 --- Comment #10 from Mark Millard <markmi@dsl-only.net> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219153-29464-RRbYooPjK2>