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

Wed May 10 21:50:45 UTC 2017

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

--- Comment #7 from Mark Millard <markmi at dsl-only.net> ---
(In reply to John Baldwin from comment #5)

This note is for the /usr/local/bin/gdb crash.

As for building ports with debug information, I use
as a default context:

# svnlite diff /usr/ports/Mk/
Index: /usr/ports/Mk/bsd.port.mk
===================================================================
--- /usr/ports/Mk/bsd.port.mk   (revision 440115)
+++ /usr/ports/Mk/bsd.port.mk   (working copy)
@@ -1639,7 +1639,11 @@
 STRIP_CMD=     ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
+.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
+CFLAGS:=               ${CFLAGS} ${DEBUG_FLAGS}
+.else
 CFLAGS:=               ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+.endif
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=       ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif

and:

# more /etc/make.conf 
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=6
WRKDIRPREFIX=/usr/obj/portswork
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CURDIR:M*/www/webkit-qt5*}
#WITH_DEBUG=
.else
WITH_DEBUG=
.endif
WITH_DEBUG_FILES=
MALLOC_PRODUCTION=

(WITH_DEBUG= makes level/llvm40 and www/webkit-qt5
massively large, which I avoid. It has been years
since I've built or used www/webkit-qt5, however.)

An example core file bt for /usr/local/bin/gdb getting
its own segmentation fault is as follows. Note #11 and
its memaddr=8 . (#0-#10 are the attempted handling of
the bad (and incorrect?) address, but the attempt got
its own failure.)

#0  0x430935d0 in _Unwind_SetGR (context=<value optimized out>, index=<value
optimized out>, val=1130509136) at unwind-dw2-fde.h:162
162     {
Cannot find new threads: generic error
(gdb) bt
#0  0x430935d0 in _Unwind_SetGR (context=<value optimized out>, index=<value
optimized out>, val=1130509136) at unwind-dw2-fde.h:162
#1  0x432c53b8 in __gxx_personality_v0 (version=<value optimized out>,
actions=6, exception_class=<value optimized out>, ue_header=0x43623350,
context=0xffffd0a0)
    at
/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:681
#2  0x43094234 in _Unwind_RaiseException_Phase2 (exc=<value optimized out>,
context=<value optimized out>) at unwind.inc:66
#3  0x43093e10 in _Unwind_RaiseException (exc=0xffffd0a0) at unwind.inc:135
#4  0x432c4778 in __cxa_throw (obj=<value optimized out>, tinfo=<value
optimized out>, dest=<value optimized out>) at
/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:71
#5  0x01c9f398 in throw_exception_cxx (exception={reason = RETURN_ERROR, error
= MEMORY_ERROR, message = 0x43748400 "Cannot access memory at address 0x8"}) at
./common/common-exceptions.c:303
#6  0x01c9f42c in throw_exception (exception=Cannot access memory at address
0x0
) at ./common/common-exceptions.c:317
#7  0x01c9f4f8 in throw_it (reason=1130509136, error=MEMORY_ERROR, fmt=<value
optimized out>, ap=<value optimized out>) at ./common/common-exceptions.c:373
#8  0x01c9f5ec in throw_verror (error=<value optimized out>, fmt=<value
optimized out>, ap=<value optimized out>) at ./common/common-exceptions.c:379
#9  0x01c9f65c in throw_error (error=<value optimized out>, fmt=<value
optimized out>) at ./common/common-exceptions.c:394
#10 0x01bedcf8 in memory_error (err=<value optimized out>, memaddr=<value
optimized out>) at corefile.c:237
#11 0x01bedfbc in read_memory_object (object=TARGET_OBJECT_MEMORY, memaddr=8,
myaddr=0xffffd940 "???`C\027\024????????\033???p", len=<value optimized out>)
at corefile.c:261
#12 0x01bee1b0 in read_memory_typed_address (addr=<value optimized out>,
type=0x438e0018) at corefile.c:400
#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
#15 0x019b4e40 in svr4_current_sos () at solib-svr4.c:1528
#16 0x01c71264 in update_solib_list (from_tty=26952375, target=<value optimized
out>) at solib.c:767
#17 0x01c71b4c in solib_add (pattern=0x0, from_tty=0, target=0x2d43100,
readsyms=1) at solib.c:994
#18 0x01b33eb4 in post_create_inferior (target=0x2d43100, from_tty=1) at
infcmd.c:461
#19 0x01ade424 in core_open (arg=<value optimized out>, from_tty=1) at
corelow.c:407
#20 0x01bee65c in core_file_command (filename=0xffffde21
"/var/crash/a.out.29973.core", from_tty=1) at corefile.c:77
#21 0x01b583b8 in catch_command_errors (command=0x1bee610
<core_file_command(char*, int)>, arg=<value optimized out>, from_tty=1) at
main.c:375
#22 0x01b593f0 in captured_main (data=<value optimized out>) at main.c:1081
#23 0x01b596ac in gdb_main (args=0xffffdcb8) at main.c:1159
#24 0x01890d54 in main (argc=<value optimized out>, argv=0xffffdcfc) at
gdb.c:38
Current language:  auto; currently minimal

The original program /usr/local/bin/gdb was looking at was a simple
C++ exception handling test compiled by system-clang++ on a world
built by system-clang. (Tied to my getting evidence of things for
the 2 folks working on things for targeting powerpc via clang.)
That original a.out gets its own segmentation fault due to what
clang generated.

-- 
You are receiving this mail because:
You are the assignee for the bug.
