We recently enabled crt for powerpc in
https://reviews.llvm.org/rGb7611ad0b16769d3bf172e84fa9296158f8f1910.
And we started to see some unexpected error message when running
check-runtimes.
eg:
https://lab.llvm.org/buildbot/#/builders/57/builds/9488/steps/6/logs/stdio
line 100 - 103:
"
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
"
Looks like we shouldn't strip the space at the beginning,
or else the command line passed to subprocess won't work well.
Reviewed By: phosek, MaskRay
Differential Revision: https://reviews.llvm.org/D108329
New ports in glibc typically don't define ELF_INITFINI, so
DT_INIT/DT_FINI support is disabled.
(rhel ppc64le likely patches their glibc this way as well.)
musl can disable DT_INIT/DT_FINI via -DNO_LEGACY_INITFINI.
So we cannot guarantee ctor()/dtor() will be printed.
These compiler-rt tests should be UNSUPPORTED instead of XFAIL, which seems to be the real intent of the authors.
Reviewed By: vvereschaka
Differential Revision: https://reviews.llvm.org/D89840
Summary:
These changes are necessary to support remote running compiler-rt tests
that were compiled on Windows.
Most of the code here has been copy-pasted from other lit configs.
Why do we remove the conversions to ASCII in the crt config?
We set the `universal_newlines` argument to `True` in `Popen` instead.
This is supported in both Python 2.7 and 3, is easier
(no need to do the `str(dir.decode('ascii'))` dance) and less
error prone.
Also, this is necessary because if the config is executed on Windows,
and `execute_external` is `True`, we take the branch
`if sys.platform in ['win32'] and execute_external`,
and if we use Python 3, then the `dir` variable is a byte-like object,
not str, but the ``replace method on byte-like objects requires its
arguments to also be byte-like objects, which is incompatible with
Python 2 etc etc.
It is a lot simpler to just work with strings in the first place, which
is achieved by setting `universal_newlines` to `True`. As far as
I understand, this way wasn't taken because of the need to support
Python <2.7, but this is not the case now.
Reviewers: compnerd, phosek, weimingz
Reviewed By: compnerd
Subscribers: dberris, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D83485
Summary:
The `execute_external` global variable is defined in [`lit.common.cfg.py`](fcfb3170a7/compiler-rt/test/lit.common.cfg.py (L18-L27)) and used here (on lines 23 and 39). However, this variable is not visible in configs that are loaded independently.
Explicitly assign it to the correct value to avoid `NameError`.
Reviewers: compnerd, phosek
Reviewed By: compnerd, phosek
Subscribers: dberris, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79892
Summary:
This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
llvm-svn: 364591
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359591
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359576
Jinsong Ji