Date: Wed, 10 May 2017 21:50:45 +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-L85e2ypLUr@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 #7 from Mark Millard <markmi@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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 440115) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1639,7 +1639,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif and: # more /etc/make.conf=20 WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D6 WRKDIRPREFIX=3D/usr/obj/portswork # # From a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D (WITH_DEBUG=3D 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=3D8 . (#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=3D<value optimized out>, index=3D<= value optimized out>, val=3D1130509136) at unwind-dw2-fde.h:162 162 { Cannot find new threads: generic error (gdb) bt #0 0x430935d0 in _Unwind_SetGR (context=3D<value optimized out>, index=3D<= value optimized out>, val=3D1130509136) at unwind-dw2-fde.h:162 #1 0x432c53b8 in __gxx_personality_v0 (version=3D<value optimized out>, actions=3D6, exception_class=3D<value optimized out>, ue_header=3D0x4362335= 0, context=3D0xffffd0a0) at /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_personal= ity.cc:681 #2 0x43094234 in _Unwind_RaiseException_Phase2 (exc=3D<value optimized out= >, context=3D<value optimized out>) at unwind.inc:66 #3 0x43093e10 in _Unwind_RaiseException (exc=3D0xffffd0a0) at unwind.inc:1= 35 #4 0x432c4778 in __cxa_throw (obj=3D<value optimized out>, tinfo=3D<value optimized out>, dest=3D<value optimized out>) at /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc= :71 #5 0x01c9f398 in throw_exception_cxx (exception=3D{reason =3D RETURN_ERROR= , error =3D MEMORY_ERROR, message =3D 0x43748400 "Cannot access memory at address 0= x8"}) at ./common/common-exceptions.c:303 #6 0x01c9f42c in throw_exception (exception=3DCannot access memory at addr= ess 0x0 ) at ./common/common-exceptions.c:317 #7 0x01c9f4f8 in throw_it (reason=3D1130509136, error=3DMEMORY_ERROR, fmt= =3D<value optimized out>, ap=3D<value optimized out>) at ./common/common-exceptions.c= :373 #8 0x01c9f5ec in throw_verror (error=3D<value optimized out>, fmt=3D<value optimized out>, ap=3D<value optimized out>) at ./common/common-exceptions.c= :379 #9 0x01c9f65c in throw_error (error=3D<value optimized out>, fmt=3D<value optimized out>) at ./common/common-exceptions.c:394 #10 0x01bedcf8 in memory_error (err=3D<value optimized out>, memaddr=3D<val= ue optimized out>) at corefile.c:237 #11 0x01bedfbc in read_memory_object (object=3DTARGET_OBJECT_MEMORY, memadd= r=3D8, myaddr=3D0xffffd940 "???`C\027\024????????\033???p", len=3D<value optimized= out>) at corefile.c:261 #12 0x01bee1b0 in read_memory_typed_address (addr=3D<value optimized out>, type=3D0x438e0018) at corefile.c:400 #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 #15 0x019b4e40 in svr4_current_sos () at solib-svr4.c:1528 #16 0x01c71264 in update_solib_list (from_tty=3D26952375, target=3D<value o= ptimized out>) at solib.c:767 #17 0x01c71b4c in solib_add (pattern=3D0x0, from_tty=3D0, target=3D0x2d4310= 0, readsyms=3D1) at solib.c:994 #18 0x01b33eb4 in post_create_inferior (target=3D0x2d43100, from_tty=3D1) at infcmd.c:461 #19 0x01ade424 in core_open (arg=3D<value optimized out>, from_tty=3D1) at corelow.c:407 #20 0x01bee65c in core_file_command (filename=3D0xffffde21 "/var/crash/a.out.29973.core", from_tty=3D1) at corefile.c:77 #21 0x01b583b8 in catch_command_errors (command=3D0x1bee610 <core_file_command(char*, int)>, arg=3D<value optimized out>, from_tty=3D1)= at main.c:375 #22 0x01b593f0 in captured_main (data=3D<value optimized out>) at main.c:10= 81 #23 0x01b596ac in gdb_main (args=3D0xffffdcb8) at main.c:1159 #24 0x01890d54 in main (argc=3D<value optimized out>, argv=3D0xffffdcfc) 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. --=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-L85e2ypLUr>