Commit Graph

143 Commits

Author SHA1 Message Date
Dimitry Andric
5866c369e4 Revert libunwind change to fix backtrace segfault on aarch64
Revert commit 22b615a96593 from llvm git (by Daniel Kiss):

  [libunwind] Support for leaf function unwinding.

  Unwinding leaf function is useful in cases when the backtrace finds a
  leaf function for example when it caused a signal.
  This patch also add the support for the DW_CFA_undefined because it marks
  the end of the frames.

  Ryan Prichard provided code for the tests.

  Reviewed By: #libunwind, mstorsjo

  Differential Revision: https://reviews.llvm.org/D83573

  Reland with limit the test to the x86_64-linux target.

Bisection has shown that this particular upstream commit causes programs
using backtrace(3) on aarch64 to segfault. This affects the lang/rust
port, for instance. Until we can upstream to fix this problem, revert
the commit for now.

Reported by:	mikael
PR:		256864
2021-07-03 00:35:49 +02:00
Ed Maste
b762974cf4 clang: stop linking _p libs for -pg as of FreeBSD 14
In FreeBSD 14 we will stop providing _p libraries (compiled with -pg).

Reviewed by:	dim (upstream)
Obtained from:	LLVM 699d47472c3f
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D30861
2021-06-27 13:12:12 -04:00
Dimitry Andric
014a40f8f6 Disable llvm generating 128-bit multiply libcalls on 32-bit ARM
Merge commit 789708617d20 from llvm git (Koutheir Attouchi):

  Do not generate calls to the 128-bit function __multi3() on 32-bit ARM

  Re-applying this patch after bots failures. Should be fine now.

  The function __multi3() is undefined on 32-bit ARM, so a call to it should
  never be emitted. Instead, plain instructions need to be generated to
  perform 128-bit multiplications.

  Differential Revision: https://reviews.llvm.org/D103906

Reported by:	mmel
MFC after:	3 days
2021-06-22 22:26:13 +02:00
Dimitry Andric
e7e517981a Fix clang assertion while building recent www/chromium
Merge commit c8227f06b335 from llvm git (by Arthur Eubanks):

  [clang] Don't assert in EmitAggregateCopy on trivial_abi types

  Fixes PR42961.

  Reviewed By: rnk

  Differential Revision: https://reviews.llvm.org/D97872

PR:		256721, 255570
Reported by:	jbeich
MFC after:	3 days
2021-06-21 20:48:37 +02:00
Dimitry Andric
23408297fb Merge llvm-project 12.0.1 rc2
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.1-rc2-0-ge7dac564cd0e, a.k.a. 12.0.1 rc2.

PR:		255570
MFC after:	6 weeks
2021-06-19 20:09:28 +02:00
Dimitry Andric
d099db2546 Apply upstream libc++ fix to allow building with devel/xxx-xtoolchain-gcc
Merge commit 52e9d80d5db2 from llvm git (by Jason Liu):

  [libc++] add `inline` for __open's definition in ifstream and ofstream

  Summary:

  When building with gcc on AIX, it seems that gcc does not like the
  `always_inline` without the `inline` keyword.
  So adding the inline keywords in for __open in ifstream and ofstream.
  That will also make it consistent with __open in basic_filebuf
  (it seems we added `inline` there before for gcc build as well).

  Differential Revision: https://reviews.llvm.org/D99422

PR:		255570
MFC after:	6 weeks
2021-06-14 20:44:09 +02:00
Dimitry Andric
715df83abc Disable strict-fp for powerpcspe, as it does not work properly yet
Merge commit 5c18d1136665 from llvm git (by Qiu Chaofan)

  [SPE] Disable strict-fp for SPE by default

  As discussed in PR50385, strict-fp on PowerPC SPE has not been
  handled well. This patch disables it by default for SPE.

  Reviewed By: nemanjai, vit9696, jhibbits

  Differential Revision: https://reviews.llvm.org/D103235

PR:		255570
MFC after:	6 weeks
2021-06-14 18:10:03 +02:00
Dimitry Andric
d409305fa3 Merge llvm-project 12.0.0 release
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR:		255570
MFC after:	6 weeks
2021-06-13 22:01:15 +02:00
Dimitry Andric
e8d8bef961 Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR:		255570
MFC after:	6 weeks
2021-06-13 21:37:19 +02:00
Dimitry Andric
1b00608b26 Merge llvm commits for kernel address and memory sanitizer support
Merge commit 99eca1bd9c7a from llvm git (by Mark Johnston):

  [Driver] Enable kernel address and memory sanitizers on FreeBSD

  Test Plan: using kernel ASAN and MSAN implementations in FreeBSD

  Reviewed By: emaste, dim, arichardson

  Differential Revision: https://reviews.llvm.org/D98286

Merge commit f511dc75e4c1 from llvm git (by Mark Johnston):

  [asan] Add an offset for the kernel address sanitizer on FreeBSD

  This is based on a port of the sanitizer runtime to the FreeBSD kernel
  that has been commited as https://cgit.freebsd.org/src/commit/?id=38da497a4dfcf1979c8c2b0e9f3fa0564035c147
  and the following commits.

  Reviewed By: emaste, dim
  Differential Revision: https://reviews.llvm.org/D98285

Requested by:	markj
MFC after:	3 days
2021-04-27 21:18:13 +02:00
Ed Maste
19587d7422 clang: Fix -gz=zlib options for linker
Clang commit ccb4124a4172bf2cb2e1cd7c253f0f1654fce294:

Fix -gz=zlib options for linker

gcc translates -gz=zlib to --compress-debug-options=zlib for both
assembler and linker but clang only does this for assembler.

The linker needs --compress-debug-options=zlib option to compress the
debug sections in the generated executable or shared library.

Due to this bug, -gz=zlib has no effect on the generated executable or
shared library.

This patch fixes that.

Clang commit 462cf39a5c180621b56f7602270ce33eb7b68d23:

[Driver] Fix -gz=zlib options for linker also on FreeBSD

ccb4124a4172 fixed translating -gz=zlib to --compress-debug-sections for
linker invocation for several ToolChains, but omitted FreeBSD.

Approved by:	dim
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D29028
2021-03-04 15:10:03 -05:00
Dimitry Andric
e63539f305 Fix clang assertion when compiling the devel/onetbb port
Merge commit 740a164de from llvm git (by Richard Smith):

  PR46377: Fix dependence calculation for function types and typedef
  types.

  We previously did not treat a function type as dependent if it had a
  parameter pack with a non-dependent type -- such a function type depends
  on the arity of the pack so is dependent even though none of the
  parameter types is dependent. In order to properly handle this, we now
  treat pack expansion types as always being dependent types (depending on
  at least the pack arity), and always canonically being pack expansion
  types, even in the unusual case when the pattern is not a dependent
  type. This does mean that we can have canonical types that are pack
  expansions that contain no unexpanded packs, which is unfortunate but
  not inaccurate.

  We also previously did not treat a typedef type as
  instantiation-dependent if its canonical type was not
  instantiation-dependent. That's wrong because instantiation-dependence
  is a property of the type sugar, not of the type; an
  instantiation-dependent type can have a non-instantiation-dependent
  canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

  PR46637: Fix handling of placeholder types in trailing-return-types.

  Only permit a placeholder type in a trailing-return-type if it would
  also have been permitted in the decl-specifier sequence of a
  corresponding declaration with no trailing-return-type. The standard
  doesn't actually say this, but this is the only thing that makes sense.

  Also fix handling of an 'auto' in a trailing-return-type in a parameter
  of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

  Don't crash if we deserialize a pack expansion type whose pattern
  contains no packs.

  Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR:		252892
Reported by:	thierry
MFC after:	3 days
2021-01-26 17:51:25 +01:00
Dimitry Andric
86d2671e3e Update contrib/llvm-project/FREEBSD-Xlist for llvmorg-11.0.1-rc2.
MFC after:	4 weeks
X-MFC-With:	r364284
2021-01-03 14:21:54 +01:00
Dimitry Andric
eaeb601bd6 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.1-rc2-0-g43ff75f2c3f (aka 11.0.1 rc2).

MFC after:	4 weeks
X-MFC-With:	r364284
2021-01-03 13:54:24 +01:00
Dimitry Andric
543478be75 Merge commit 4f568fbd2 from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not emit HW loop when TLS var accessed in PHI of loop
  exit

  If any PHI nodes in loop exit blocks have incoming values from the
  loop that are accesses of TLS variables with local dynamic or general
  dynamic TLS model, the address will be computed inside the loop.
  Since this includes a call to __tls_get_addr, this will in turn cause
  the CTR loops verifier to complain. Disable CTR loops in such cases.

  Fixes: https://bugs.llvm.org/show_bug.cgi?id=48527

This should fix building ceph 12.2.12 on powerpc64, powerpc, powerpcspe
and powerpc64le.

Requested by:	pkubaj
MFC after:	3 days
2021-01-01 15:35:13 +01:00
Dimitry Andric
6813f2420b Merge commit 28de0fb48 from llvm git (by Luís Marques):
[RISCV] Set __GCC_HAVE_SYNC_COMPARE_AND_SWAP_x defines

  The RISCV target did not set the GCC atomic compare and swap defines,
  unlike other targets. This broke builds for things like glib on
  RISCV.

  Patch by Kristof Provost (kprovost)

  Differential Revision: https://reviews.llvm.org/D91784

This should fix building glib20 on RISC-V and unblock a number of
dependent ports.

Requested by:	kp
MFC after:	3 days
2020-12-09 18:37:43 +00:00
Dimitry Andric
c3f7be36e8 Merge commit d989ffd10 from llvm git (by Dimitry Andric):
Implement computeHostNumHardwareThreads() for FreeBSD

  This retrieves CPU affinity via FreeBSD's cpuset(2) API, and makes
  LLVM respect affinity settings configured by the user via the
  cpuset(1) command.

  In particular, this allows to reduce the number of threads used on
  machines with high core counts, which can interact badly with
  parallelized build systems. This is particularly noticable with lld,
  which spawns lots of threads even for linking e.g. hello_world!

  This fix is related to PR48193, but does not adress the more
  fundamental problem, which is that LLVM by default grabs as many CPUs
  and/or threads as possible.

  Reviewed By: MaskRay

  Differential Revision: https://reviews.llvm.org/D92271

Originally by:	mjg
MFC after:	1 week
2020-12-03 19:29:18 +00:00
Dimitry Andric
5cc6cb2645 Revert r367815, so we can apply the slightly different version that
landed upstream:

For llvm's internal function which retrieves the number of available
"hardware threads", use cpuset_getaffinity(2) on FreeBSD, so it will
honor processor sets configured by the cpuset(1) command.

This should make it possible to avoid e.g. lld creating a huge number of
threads on a machine with many cores, even for linking simple programs.

This will also be submitted upstream.

Submitted by:	mjg
2020-12-03 19:26:21 +00:00
Ed Maste
3063e1e56b clang: allow -fstack-clash-protection on FreeBSD
-fstack-clash-protection was added in Clang commit e67cbac81211 but was
enabled only on Linux.  It should work fine on FreeBSD as well, so
enable it.

To be discussed and upstreamed with a test.  The OS test should probably
just be removed.

Reviewed by:	dim
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D27366
2020-11-25 14:26:13 +00:00
Dimitry Andric
991f6e7534 For llvm's internal function which retrieves the number of available
"hardware threads", use cpuset_getaffinity(2) on FreeBSD, so it will
honor processor sets configured by the cpuset(1) command.

This should make it possible to avoid e.g. lld creating a huge number of
threads on a machine with many cores, even for linking simple programs.

This will also be submitted upstream.

Submitted by:	mjg
MFC after:	1 week
2020-11-18 19:55:24 +00:00
Dimitry Andric
2418469b60 Merge commit 8df4e6094 from llvm git (by Fangrui Song):
[ELF] Don't consider SHF_ALLOC ".debug*" sections debug sections

  Fixes PR48071

  * The Rust compiler produces SHF_ALLOC `.debug_gdb_scripts` (which
    normally does not have the flag)
  * `.debug_gdb_scripts` sections are removed from `inputSections` due
    to --strip-debug/--strip-all
  * When processing --gc-sections, pieces of a SHF_MERGE section can be
    marked live separately

  `=>` segfault when marking liveness of a `.debug_gdb_scripts` which
  is not split into pieces (because it is not in `inputSections`)

  This patch circumvents the problem by not treating SHF_ALLOC
  ".debug*" as debug sections (to prevent --strip-debug's stripping)
  (which is still useful on its own).

  Reviewed By: grimar

  Differential Revision: https://reviews.llvm.org/D91291

This should fix lld segfaulting when linking the rust-based parts of the
devel/py-maturin port.

Reported by:	Nick Venenga <nijave@gmail.com>
PR:		250783
MFC after:	3 days
2020-11-12 19:25:31 +00:00
Dimitry Andric
1ee2434eb5 Merge commit 354d3106c from llvm git (by Kai Luo):
[PowerPC] Skip combining (uint_to_fp x) if x is not simple type

  Current powerpc64le backend hits
  ```
  Combining: t7: f64 = uint_to_fp t6
  llc: llvm-project/llvm/include/llvm/CodeGen/ValueTypes.h:291:
  llvm::MVT llvm::EVT::getSimpleVT() const: Assertion `isSimple() &&
  "Expected a SimpleValueType!"' failed.
  ```
  This patch fixes it by skipping combination if `t6` is not simple
  type.
  Fixed https://bugs.llvm.org/show_bug.cgi?id=47660.

  Reviewed By: #powerpc, steven.zhang

  Differential Revision: https://reviews.llvm.org/D88388

This should fix the llvm assertion mentioned above when building the
following ports for powerpc64le:

* audio/traverso
* databases/percona57-pam-for-mysql
* databases/percona57-server
* emulators/citra
* emulators/citra-qt5
* games/7kaa
* graphics/dia
* graphics/mandelbulber
* graphics/pcl-pointclouds
* net-p2p/libtorrent-rasterbar
* textproc/htmldoc

Requested by:	pkubaj
MFC after:	3 days
2020-11-08 12:47:35 +00:00
Adrian Chadd
d061adc48d [libcxx] Fix atomic type for mips32 on gcc to work w/out needing libatomic
When compiling this for mips32 on gcc-6.x, we'd hit issues where we
don't have 64 bit atomics on mips32.

gcc implements this using libatomic, which we don't currently include
in our freebsd-gcc compiler packages.

So for now add this work around so mips32 works.  It's also fine for
mips64.  We can fix this later once we get libatomic included.

Approved by:	dim
Differential Revision:	https://reviews.freebsd.org/D26774
2020-10-18 17:31:10 +00:00
Dimitry Andric
f845673b24 Merge commit 35ecc7fe4 from llvm git (by Hubert Tong):
[clang][Sema] Fix PR47676: Handle dependent AltiVec C-style cast

  Fix premature decision in the presence of type-dependent expression
  operands on whether AltiVec vector initializations from single
  expressions are "splat" operations.

  Verify that the instantiation is able to determine the correct cast
  semantics for both the scalar type and the vector type case.

  Note that, because the change only affects the single-expression case
  (and the target type is an AltiVec-style vector type), the
  replacement of a parenthesized list with a parenthesized expression
  does not change the semantics of the program in a program-observable
  manner.

  Reviewed By: aaron.ballman

  Differential Revision: https://reviews.llvm.org/D88526

This should fix 'Assertion failed: (isScalarType()), function
getScalarTypeKind, file /usr/src/contrib/llvm-project/clang/lib/AST
/Type.cpp, line 2146', when building the graphics/opencv-core port for
powerpc64le.

Requested by:	pkubaj
MFC after:	4 weeks
X-MFC-With:	r364284
2020-10-13 19:42:22 +00:00
Dimitry Andric
f91b0c1c18 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.0-0-g176249bd673 (aka 11.0.0 release).

MFC after:	4 weeks
X-MFC-With:	r364284
2020-10-12 21:35:29 +00:00
Dimitry Andric
8833aad7be Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.0-rc5-0-g60a25202a7d.

MFC after:	4 weeks
X-MFC-With:	r364284
2020-10-01 19:06:07 +00:00
Dimitry Andric
82bf979d53 Merge commit 46673763f from llvm git (by Craig Topper):
[X86] Place new constant node in topological order in
  X86DAGToDAGISel::matchBitExtract

  Fixes PR47482

This should fix 'Assertion failed: (Op->getNodeId() != -1 && "Node has
already selected predecessor node"), function DoInstructionSelection,
file
/usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp,
line 1149' when compiling part of the project_painter project, while
targeting the bdver2 (or higher) CPU.

Reported by:	jkim
MFC after:	6 weeks
X-MFC-With:	r364284
2020-09-17 19:47:41 +00:00
Dimitry Andric
927c847d5f Merge commit e09107ab8 from llvm git (by Raul Tambre):
[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

  Instead of relying on whether a certain identifier is a builtin,
  introduce BuiltinAttr to specify a declaration as having builtin
  semantics.

  This fixes incompatible redeclarations of builtins, as reverting the
  identifier as being builtin due to one incompatible redeclaration
  would have broken rest of the builtin calls.
  Mostly-compatible redeclarations of builtins also no longer have
  builtin semantics. They don't call the builtin nor inherit their
  attributes.
  A long-standing FIXME regarding builtins inside a namespace enclosed
  in extern "C" not being recognized is also addressed.

  Due to the more correct handling attributes for builtin functions are
  added in more places, resulting in more useful warnings.
  Tests are updated to reflect that.

  Intrinsics without an inline definition in intrin.h had `inline` and
  `static` removed as they had no effect and caused them to no longer
  be recognized as builtins otherwise.

  A pthread_create() related test is XFAIL-ed, as it relied on it being
  recognized as a builtin based on its name.
  The builtin declaration syntax is too restrictive and doesn't allow
  custom structs, function pointers, etc.
  It seems to be the only case and fixing this would require reworking
  the current builtin syntax, so this seems acceptable.

  Fixes PR45410.

  Reviewed By: rsmith, yutsumi

  Differential Revision: https://reviews.llvm.org/D77491

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by:	zeising
MFC after:	6 weeks
X-MFC-With:	r364284
2020-09-17 19:43:25 +00:00
Dimitry Andric
16d6b3b3da Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.0-rc2-91-g6e042866c30.

MFC after:	6 weeks
X-MFC-With:	r364284
2020-09-16 16:58:29 +00:00
Brandon Bergren
33fa4ac54f [PowerPC64LE] Fix platform definitions for powerpc64le-*-freebsd*
Teach clang that powerpc64le-*-freebsd* is a valid triple.

This is already in upstream clang, but was too late for llvm 11.0.0.
Apply it directly for now, until it can be backported to llvm 11.0.1.

See upstream https://reviews.llvm.org/D73425 for details.

Reviewed by:	dim (upstream version), emaste
Approved by:	emaste
Differential Revision:	https://reviews.freebsd.org/D26400
2020-09-12 18:23:27 +00:00
Dimitry Andric
9fc62ba649 Merge commit e6bb4c8e7 from llvm git (by Craig Topper):
[X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend.

  SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when
  switching the code to being table based in D83273.

  Fixes PR47464

This should fix builds with -march=amdfam10 emitting SSSE3 instructions
such as pshufb, which lead to programs crashing with SIGILL on such
processors.

Reported by:	avg
MFC after:	6 weeks
X-MFC-With:	r364284
2020-09-09 18:11:04 +00:00
Dimitry Andric
016c61beed Merge commit 47b0262d3 from llvm git (by me):
Add <stdarg.h> include to kmp_os.h, to get the va_list type, required
  after cde8f4c164a2. Sort system includes, while here.

The original merged commit works fine by itself on head, but fails to
compile on stable branches because stdarg.h is not implicitly pulled in.

MFC after:	immediately, to fix failing builds on stable/{11,12}
2020-09-07 20:10:03 +00:00
Dimitry Andric
031db28b2b Merge commit f26fc568402f from llvm git (by me):
Eliminate the sizing template parameter N from CoalescingBitVector

  Since the parameter is not used anywhere, and the default size of 16
  apparently causes PR47359, remove it. This ensures that IntervalMap
  will automatically determine the optimal size, using its NodeSizer
  struct.

  Reviewed By: dblaikie

  Differential Revision: https://reviews.llvm.org/D87044

This should fix 'Assertion failed: (Elements + Grow <= Nodes * Capacity
&& "Not enough room for elements"), function distribute, file
/usr/src/contrib/llvm-project/llvm/lib/Support/IntervalMap.cpp, line
123.' when building the x11-toolkits/py-wxPython40 port on a i386 host.

Reported by:	zeising
MFC after:	6 weeks
X-MFC-With:	r364284
2020-09-03 18:34:01 +00:00
Dimitry Andric
46c8c5540f Add atomic and bswap functions to libcompiler_rt
There have been several mentions on our mailing lists about missing
atomic functions in our system libraries (e.g. __atomic_load_8 and
friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.

To address this, add implementations for the functions from compiler-rt
to the system compiler support libraries, e.g. libcompiler_rt.a and and
libgcc_s.so.

This also needs a small fixup in compiler-rt's atomic.c, to ensure that
32-bit mips can build correctly.

Bump __FreeBSD_version to make it easier for port maintainers to detect
when these functions were added.

MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D26159
2020-08-25 06:49:10 +00:00
Dimitry Andric
16794618f7 Merge commit cde8f4c16 from llvm git (by me):
Move special va_list handling to kmp_os.h

  Instead of copying and pasting the same #ifdef expressions in
  multiple places, define a type and a pair of macros in kmp_os.h, to
  handle whether va_list is pointer-like or not:

  * kmp_va_list is the type to use for __kmp_fork_call()
  * kmp_va_deref() dereferences a va_list, if necessary
  * kmp_va_addr_of() takes the address of a va_list, if necessary

  Also add FreeBSD to the list of OSes that has a non pointer-like
  va_list. This can now be easily extended to other OSes too.

  Reviewed By: AndreyChurbanov

  Differential Revision: https://reviews.llvm.org/D86397

This should enable building of LLVM's OpenMP on AArch64. Addition to
share/mk will follow in a subsequent commit.

PR:		248864
MFC after:	2 weeks
2020-08-24 20:37:18 +00:00
Dimitry Andric
75b4d546cd Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.0-rc2-0-g414f32a9e86.

MFC after:	6 weeks
X-MFC-With:	r364284
2020-08-24 17:43:23 +00:00
Dimitry Andric
1e991466c3 Merge commit 1ce07cd614be from llvm git (by me):
Instantiate Error in Target::GetEntryPointAddress() only when
  necessary

  When Target::GetEntryPointAddress() calls
  exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
  entry_addr is valid, it can immediately be returned.

  However, just before that, an llvm::Error value has been setup, but
  in this case it is not consumed before returning, like is done
  further below in the function.

  In https://bugs.freebsd.org/248745 we got a bug report for this,
  where a very simple test case aborts and dumps core:

  * thread #1, name = 'testcase', stop reason = breakpoint 1.1
      frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
     1    int main(int argc, char *argv[])
     2    {
  -> 3        return 0;
     4    }
  (lldb) p argc
  Program aborted due to an unhandled Error:
  Error value was Success. (Note: Success values must still be checked prior to being destroyed).

  Thread 1 received signal SIGABRT, Aborted.
  thr_kill () at thr_kill.S:3
  3       thr_kill.S: No such file or directory.
  (gdb) bt
  #0  thr_kill () at thr_kill.S:3
  #1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
  #2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
  #3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
  #4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
  #5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
  #6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
  #7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
  #8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
  #9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
  #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
  #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
  #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
  #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
  #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
  #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
  #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
  #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
  #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
  #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
  #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
  #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
  #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
  #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
  #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
  #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890

  Fix the incorrect error catch by only instantiating an Error object
  if it is necessary.

  Reviewed By: JDevlieghere

  Differential Revision: https://reviews.llvm.org/D86355

This should fix lldb aborting as described in the scenario above.

Reported by:	dmgk
PR:		248745
2020-08-22 10:55:55 +00:00
Dimitry Andric
2a99bea578 Merge commit 95e18b2d9d5f from llvm git (by Kang Zhang):
[PowerPC] Fix a typo for InstAlias of mfsprg

  D77531 has a type for mfsprg, it should be mtsprg. This patch is to
  fix this typo.

This should fix booting powerpc64 kernels, after LLVM 11 was imported.

PR:		248763
2020-08-21 10:06:01 +00:00
Dimitry Andric
987992b128 Merge commit 4d52ebb9b9c7 from llvm git (by Chen Zheng):
[PowerPC] Make StartMI ignore COPY like instructions.

  Reviewed By: lkail

  Differential Revision: https://reviews.llvm.org/D85659

This fixes an assertion failure when building world for powerpc. It was
reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=47041>.
2020-08-17 16:37:46 +00:00
Dimitry Andric
30e9d23b5b Revert r364275, for reapplying the final upstream fix:
Tentatively apply https://reviews.llvm.org/D85659, which fixes an
assertion failure when building world for powerpc. This has been
reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=47041>.
2020-08-17 16:34:10 +00:00
Dimitry Andric
b4e0f677d9 Tentatively apply https://reviews.llvm.org/D85659, which fixes an
assertion failure when building world for powerpc. This has been
reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=47041>.
2020-08-16 18:10:15 +00:00
Dimitry Andric
9ff1cc58cd Temporarily disable libunwind's FrameHeaderCache, until there is a
resolution for <https://bugs.llvm.org/show_bug.cgi?id=47181>.

The cache implementation depends on dl_iterate_phdr(3) ensuring that its
callbacks are not called simultaneously for multiple threads, but that
is only the case for the dl_iterate_phdr() implementation in rtld.

In a statically linked executable, libc's dl_iterate_phdr() is used,
which does no such locking. If multiple threads then call into the
unwinder at the same time, it is possible to trigger a segfault.

In particular, the statically linked lld which is built during the
cross-tools stage can segfault in this way, because it starts multiple
worker threads that can exit in parallel. Since our pthread_exit(3)
invokes the unwinder, it will therefore call into it in parallel too.
2020-08-15 22:58:07 +00:00
Dimitry Andric
1106035d5b Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
release/11.x llvmorg-11.0.0-rc1-47-gff47911ddfc.
2020-08-15 12:29:55 +00:00
Dimitry Andric
82343267e3 Reapply r362235 (by kp):
llvm: Default to -mno-relax on RISC-V

Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.

Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.

Reviewed by:	mhorne
Sponsored by:	Axiado
Differential Revision:	https://reviews.freebsd.org/D25210
2020-08-06 19:24:17 +00:00
Dimitry Andric
ec280e9ec4 Reapply r360852 (by cem):
clang: Reject %n for __attribute__((format(__freebsd_kprintf__)))

A follow-up to r360849.

Reported by:	imp
Reviewed by:	emaste, imp
Differential Revision:	https://reviews.freebsd.org/D24786
2020-08-06 19:23:00 +00:00
Dimitry Andric
497dd4e30f Reapply r359582 (by emaste):
lldb: use lua as the default script language

In the FreeBSD base system we do not have Python support in lldb, but
will have Lua support.  Make Lua the default.

This needs to be made into a configure-time option; that is being
discussed upstream and will appear in a future lldb import.  For now
carry this change as a tiny patch to our copy of lldb.
2020-08-06 19:15:31 +00:00
Dimitry Andric
0faeaeed40 r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines
[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free.  At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions  like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check.  According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by:	alfredo.junior_eldorado.org.br
Reviewed by:	jhibbits, dim

Differential Revision:	https://reviews.freebsd.org/D22549
2020-08-06 19:11:24 +00:00
Dimitry Andric
e8141ad1df Reapply r355803 (by mmel):
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original  GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.

For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)

PR:	233664
2020-08-06 19:08:28 +00:00
Dimitry Andric
998a72c55d Reapply r354347 (by cem):
Fix llvm-libunwind userspace build on ARM

GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called.  Export the same ones from LLVM-libunwind's
libgcc_s, on ARM.  As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files.  This allows
the ARM-specific Symbol.map to be included only on ARM.

Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.

No functional change intended for non-ARM architectures.

This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).
2020-08-06 19:05:59 +00:00
Dimitry Andric
45e1ec9e24 Reapply r351662 (by emaste):
lldb: shorten thread names to make logs easier to follow

lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated.  This made logs hard
to read, as the truncated thread name ran into the log message.  Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.

(Upstreaming to lldb still to be done).
2020-08-06 16:44:24 +00:00