https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219153
--- Comment #7 from Mark Millard <mar...@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. _______________________________________________ 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"