[Bug 219153] head, stable/11, release/11.0.1: libkvm (& more?) not updated to handle powerpc/powerpc64 ET_DYN based vmcore.* 's and such

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153

--- Comment #10 from Mark Millard <markmi at 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.