| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| | |
update config.{guess,sub}
|
| |/
|
|
|
| |
This change is primarily for aarch64 macOS support, since that configuration
is now properly supported upstream.
|
| |\
| |
| | |
aarch64: Fix typo
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The error was:
```
Traceback (most recent call last):
File "_generate-darwin-source-and-headers.py", line 209, in <module>
generate_source_and_headers(generate_osx=not args.only_ios, generate_ios=not args.only_osx)
File "_generate-darwin-source-and-headers.py", line 197, in generate_source_and_headers
for header_name, tag_tuples in platform_headers.iteritems():
AttributeError: 'collections.defaultdict' object has no attribute 'iteritems'
```
|
| |
|
| |
ref. https://www.fsf.org/about/contact/
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a patch pulled down from the following:
https://github.com/buildroot/buildroot/blob/78926f610b1411b03464152472fd430012deb9ac/package/libffi/0004-ffi_powerpc.h-fix-build-failure-with-powerpc7.patch
This issue is being hit on OpenBMC code when pulling the latest
libffi tag and building on a P8 ppc64le machine. I verified this
patch fixes the issue we are seeing.
Below is the original commit message:
Sicne commit 73dd43afc8a447ba98ea02e9aad4c6898dc77fb0, build on powerpc7
fails on:
In file included from ../src/powerpc/ffi.c:33:0:
../src/powerpc/ffi_powerpc.h:61:9: error: '_Float128' is not supported on this target
typedef _Float128 float128;
^~~~~~~~~
Fix this build failure by checking for __HAVE_FLOAT128 before using
_Float128, as _Float128 is enabled only on specific conditions, see
output/host/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/floatn.h:
/* Defined to 1 if the current compiler invocation provides a
floating-point type with the IEEE 754 binary128 format, and this glibc
includes corresponding *f128 interfaces for it. */
#if defined _ARCH_PWR8 && defined __LITTLE_ENDIAN__ && (_CALL_ELF == 2) \
&& defined __FLOAT128__ && !defined __NO_LONG_DOUBLE_MATH
# define __HAVE_FLOAT128 1
#else
# define __HAVE_FLOAT128 0
#endif
Fixes:
- http://autobuild.buildroot.org/results/5c9dd8fb3b6a128882b6250f197c80232d8a3b53
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Co-authored-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
|
| |
|
|
|
|
|
| |
Also fix the same error in the comment for the non-clang case.
That typo there seems to have existed since the code was written
in that form, in e7f15f60e86 - and when the clang specific codepath
was added in e3d2812ce43, the typo in the comment made it into the
actual code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
USE_BUILTIN_FFS is defined to 1 within __GNUC__, and the __builtin_ffs
function is available since GCC 3.x at least, while the ffs function
only exists on some OSes.
This fixes compilation for non-x86 mingw platforms. For x86,
USE_BUILTIN_FFS is explicitly disabled for windows targets - but
if USE_BUILTIN_FFS is enabled based on __GNUC__, it should also use
the builtin which actually is available correspondingly, not dependent
on the target OS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* aarch64: Check _WIN32 instead of _M_ARM64 for detecting windows
This fixes building for aarch64 with mingw toolchains. _M_ARM64 is
predefined by MSVC, while mingw compilers predefine __aarch64__.
In aarch64 specific code, change checks for _M_ARM64 into checks for
_WIN32.
In arch independent code, check for
(defined(_M_ARM64) || defined(__aarch64__)) && defined(_WIN32)
instead of just _M_ARM64.
In src/closures.c, coalesce checks like
defined(X86_WIN32) || defined(X86_WIN64) || defined(_M_ARM64)
into plain defined(_WIN32). Technically, this enables code for
ARM32 windows where it wasn't, but as far as I can see it, those
codepaths should be fine for that architecture variant as well.
* aarch64: Only use armasm source when building with MSVC
When building for windows/arm64 with clang, the normal gas style .S
source works fine. sysv.S and win64_armasm.S seem to be functionally
equivalent, with only differences being due to assembler syntax.
|
| |
|
|
|
|
|
| |
llvm-objdump -h does not print BFD SEC_* constants like "READONLY",
so the check will consider .eh_frame writable.
clang 11 (since https://reviews.llvm.org/D73999) will error for mismatching section flags.
Use readelf -S and check "WA" instead.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
* Try to fix RLGL_KEY nonsense
* Hard code policy bound API key
Co-authored-by: Anthony Green <green@moxielogic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2020-02-23 John David Anglin <danglin@gcc.gnu.org>
* include/ffi.h.in (FFI_CLOSURE_PTR, FFI_RESTORE_PTR): Define.
* src/closures.c (ffi_closure_alloc): Convert closure pointer
return by malloc to function pointer.
(ffi_closure_free): Convert function pointer back to malloc pointer.
* src/pa/ffi.c (ffi_closure_inner_pa32): Use union to double word
align return address on stack. Adjust statements referencing return
address. Convert closure argument from function pointer to standard
closure pointer.
(ffi_prep_closure_loc): Likewise convert closure argument back to
closure pointer. Remove assembler trampolines. Setup simulated
function descriptor as on ia64.
src/pa/ffitarget.h (FFI_TRAMPOLINE_SIZE): Reduce to 12.
src/pa/hpux32.S (ffi_closure_pa32): Retrieve closure pointer and real
gp from fake gp value in register %r19.
src/pa/linux.S (ffi_closure_pa32): Likewise.
|
| |
|
|
|
|
| |
Since x86 and x86-64 FFI_TRAMPOLINE_SIZE have been increased, we must
bump the ABI version. This fixes:
https://github.com/libffi/libffi/issues/543
|
| |
|
|
| |
Since FFI_TRAMPOLINE_SIZE is increased by 4 bytes to add ENDBR32, adjust
jump displacement by 4 bytes.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Intel Control-flow Enforcement Technology (CET):
https://software.intel.com/en-us/articles/intel-sdm
contains shadow stack (SHSTK) and indirect branch tracking (IBT). When
CET is enabled, ELF object files must be marked with .note.gnu.property
section. When Intel CET is enabled, include <cet.h> in assembly codes
to mark Intel CET support.
Also when IBT is enabled, all indirect branch targets must start with
ENDBR instruction and notrack prefix can be used to disable IBT on
indirect branch. <cet.h> defines _CET_ENDBR which can be used in
assembly codes for ENDBR instruction. If <cet.h> isn't included,
define _CET_ENDBR as empty so that _CET_ENDBR can be used in assembly
codes.
Trampoline must be enlarged to add ENDBR instruction unconditionally,
which is NOP on non-CET processors. This is required regardless if
libffi is enabled with CET since libffi.so will be marked in legacy
bitmap, but trampoline won't. Update library version for larger
FFI_TRAMPOLINE_SIZE.
This fixed:
https://github.com/libffi/libffi/issues/474
Tested with
$ CC="gcc -Wl,-z,cet-report=error -fcf-protection" CXX="g++ -Wl,-z,cet-report=error -fcf-protection" .../configure
on Linux CET machines in i686, x32 and x86-64 modes.
|
| | |
| |
| |
| |
| | |
Some of the flag bits were moved when adding powerpc64 vector support.
Fixes #536
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
| | |
|
| |
|
| |
Thank you!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Build failure looks as:
```
libtool: compile: powerpc-unknown-linux-gnu-gcc \
-O2 -mcpu=powerpc -mtune=powerpc -pipe ... -c src/powerpc/ffi.c ...
In file included from src/powerpc/ffi.c:33:
src/powerpc/ffi_powerpc.h:65:9: error: '__int128' is not supported on this target
65 | typedef __int128 float128;
| ^~~~~~~~
```
The fix avoids using __int128 in favour of aligned char[16].
Closes: https://github.com/libffi/libffi/issues/531
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
