Bug 229700 - FreeBSD clang version 6.0.0 crashed on RPI3 when building gdb-8.2
Summary: FreeBSD clang version 6.0.0 crashed on RPI3 when building gdb-8.2
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
Depends on:
Reported: 2018-07-11 13:57 UTC by Rajendra
Modified: 2020-11-27 16:25 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Rajendra 2018-07-11 13:57:34 UTC
Trying to build GDB-8.2 (gdb-8.2-branch) on RPI3.

Here is the GDB configuration:
$ configure --disable-werror --disable-nls --disable-binutils --disable-gprof --disable-gas --disable-ld --disable-gold --disable-gdbtk --prefix=<path>

clang++: error: unable to execute command: Killed
clang++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: aarch64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
clang++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
  CXX    bcache.o
  CXX    bfd-target.o
clang++: note: diagnostic msg:

Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/mi-interp-0c056e.cpp
clang++: note: diagnostic msg: /tmp/mi-interp-0c056e.sh
clang++: note: diagnostic msg:

Comment 1 John Baldwin freebsd_committer freebsd_triage 2018-09-09 04:58:04 UTC
Can you reproduce this if you cross-compile gdb?  If so, perhaps you can use creduce to get it down to a test case?  (When I test gdb and kgdb on my RPI I cross-build gdb using the 'gdb/build' script from github/bsdjhb/kgdb.git.
Comment 2 Mark Johnston freebsd_committer 2020-11-27 16:25:35 UTC
The error messages indicate that clang++ was killed due to an out-of-memory condition.  This could be a result of a bug in LLVM itself (a memory leak perhaps), but without further clues it's hard to say.  Please feel free to re-open if you're able to trigger this on 12.1 or 12.2 and believe it's a bug.