https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153
--- Comment #10 from Mark Millard <mar...@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 => /usr/local/lib/libreadline.so.6 (0x42ba4000)
libncurses.so.8 => /lib/libncurses.so.8 (0x42bfc000)
libkvm.so.7 => /lib/libkvm.so.7 (0x42c55000)
libutil.so.9 => /lib/libutil.so.9 (0x42c77000)
libthr.so.3 => /lib/libthr.so.3 (0x42c9b000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x42cd6000)
libm.so.5 => /lib/libm.so.5 (0x42cf1000)
libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x42d28000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x42f12000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x42f4b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x42f83000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x43095000)
libc.so.7 => /lib/libc.so.7 (0x430b5000)
libelf.so.2 => /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 => /usr/lib/libc++.so.1 (0x4183b000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4191e000)
libm.so.5 => /lib/libm.so.5 (0x41949000)
libc.so.7 => /lib/libc.so.7 (0x41980000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b33000)
FYI:
# ldd /usr/libexec/gdb
/usr/libexec/gdb:
libm.so.5 => /lib/libm.so.5 (0x41afa000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x41b31000)
libgnuregex.so.5 => /usr/lib/libgnuregex.so.5 (0x41b96000)
libc.so.7 => /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=0x44002084) at solib-svr4.c:913
#14 0x019b4648 in svr4_current_sos_direct (info=0x436232c0) 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=0x436232c0) at
solib-svr4.c:1494
1494 lm = solib_svr4_r_map (info);
Current language: auto; currently c++
(gdb) print *info
$1 = {debug_base = 4, debug_loader_offset_p = 0, debug_loader_offset = 0,
debug_loader_name = 0x0, main_lm_addr = 0, interp_text_sect_low = 0,
interp_text_sect_high = 0, interp_plt_sect_low = 0,
interp_plt_sect_high = 0, using_xfer = 0, probes_table = 0x0, solib_list =
0x0}
(gdb) down
#13 0x019b42b8 in solib_svr4_r_map (info=0x44002084) at solib-svr4.c:913
913 ptr_type);
(gdb) print *lmo
$2 = {r_version_offset = 0, r_version_size = 4, r_map_offset = 4, r_brk_offset
= 8, r_ldsomap_offset = 20, link_map_size = 20, l_addr_offset = 0, l_ld_offset
= 8, l_next_offset = 12,
l_prev_offset = 16, l_name_offset = 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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
