head -r343670 on armv7 (cortexA7): /rescue/WHATEVER gets "Segementation fault" in my context

Mark Millard marklmi at yahoo.com
Sun Feb 3 21:11:24 UTC 2019


I reliably get results like:

# /rescue/echo
Segmentation fault (core dumped)
#

# /rescue/tar -xpf /usr/obj/clang-armv7-installworld-poud.tar -C /usr/obj/DESTDIRs/clang-armv7-installworld-poud
Segmentation fault (core dumped)
#

That last is what I first tried /rescue with. Using just "tar" worked fine.
That in turn lead to trying other simple /rescue/WHATEVER commands.


(I've not yet figured out how to get debug information for rescue.
This limits the below information.)

Both fail at the same place:

# gdb /rescue/echo echo.15825.core 
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
. . .
Reading symbols from /rescue/echo...(no debugging symbols found)...done.
[New LWP 100179]
Core was generated by `/rescue/echo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0067b3f0 in ?? ()
(gdb) bt
#0  0x0067b3f0 in ?? ()
#1  0x0066fe28 in ?? ()
#2  0x001d11f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) disass
No function contains program counter for selected frame.


# gdb /rescue/tar tar.15819.core
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
. . .
[New LWP 100179]
Core was generated by `/rescue/tar -xpf /usr/obj/clang-armv7-installworld-poud.tar -C /usr/obj/DESTDIRs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0067b3f0 in ?? ()
(gdb) bt
#0  0x0067b3f0 in ?? ()
#1  0x0066fe28 in ?? ()
#2  0x001d11f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


The buildworld was a cross build amd64->armv7 using my historical way of building.
amd64 itself and the amd64->aarch64 cross-build that I've also built and installed
have rescue working fine. /usr/src/ is the same for all these builds (diff -r -x.svn
finds no differences).


# file /rescue/echo
/rescue/echo: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), statically linked, for FreeBSD 13.0 (1300010), FreeBSD-style, stripped

# uname -apKU
FreeBSD OPiP2E 13.0-CURRENT FreeBSD 13.0-CURRENT #4 r343670M: Fri Feb  1 16:45:22 PST 2019     markmi at FBSDFSSD:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG  arm armv7 1300010 1300010

My GENERIC-NODBG includes the standard GENERIC one and forces various debug things to be
disabled.

My builds do use -mcpu=cortex-a7 :

# more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host 
TO_TYPE=armv7
#
KERNCONF=GENERIC-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
WITH_SYSTEM_LINKER=
#
#CPUTYPE=soft
WITH_LIBCPLUSPLUS=
#WITH_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=
WITHOUT_LLVM_TARGET_AARCH64=
WITH_LLVM_TARGET_ARM=
WITHOUT_LLVM_TARGET_MIPS=
WITHOUT_LLVM_TARGET_POWERPC=
WITHOUT_LLVM_TARGET_SPARC=
WITHOUT_LLVM_TARGET_X86=
#WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
#
# Linking lldb fails for armv7
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
XCFLAGS+= -mcpu=cortex-a7
XCXXFLAGS+= -mcpu=cortex-a7
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.

I use:

# more ~/sys_build_scripts.amd64-host/make_armv7_nodebug_clang_bootstrap-amd64-host.sh 
kldload -n filemon && \
script ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host" \
WITH_META_MODE=yes \
WORLD_FLAGS="${WORLD_FLAGS} UBLDR_LOADADDR=0x42000000" \
MAKEOBJDIRPREFIX="/usr/obj/armv7_clang/arm.armv7" \
make $*


I do not know when I last tried /rescue/SOMETHING so I've no clue
when this problem started. Plus the prior build was -r341864 or
some such so this was a fairly large jump even if I used /rescue
with my prior build/installation.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list