aarch64: add PAC to GNU Notes (#882)
While PAC was enabled, the bit to indicate support in the GNU Notes section of the ELF was missing.
Before: readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI
This was caused by this file not having PAC indicated in GNU Notes and the linker discarding it: File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI
Now it has it: File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC
As well as the output shared object: readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC
Fixes: #881
Signed-off-by: Bill Roberts bill.roberts@arm.com
Status
libffi-3.4.7 was released on February 8, 2025. Check the libffi web page for updates: URL:http://sourceware.org/libffi/.
What is libffi?
Compilers for high level languages generate code that follow certain conventions. These conventions are necessary, in part, for separate compilation to work. One such convention is the “calling convention”. The “calling convention” is essentially a set of assumptions made by the compiler about where function arguments will be found on entry to a function. A “calling convention” also specifies where the return value for a function is found.
Some programs may not know at the time of compilation what arguments are to be passed to a function. For instance, an interpreter may be told at run-time about the number and types of arguments used to call a given function. Libffi can be used in such programs to provide a bridge from the interpreter program to compiled code.
The libffi library provides a portable, high level programming interface to various calling conventions. This allows a programmer to call any function specified by a call interface description at run time.
FFI stands for Foreign Function Interface. A foreign function interface is the popular name for the interface that allows code written in one language to call code written in another language. The libffi library really only provides the lowest, machine dependent layer of a fully featured foreign function interface. A layer must exist above libffi that handles type conversions for values passed between the two languages.
Supported Platforms
Libffi has been ported to many different platforms.
At the time of release, the following basic configurations have been tested:
Please send additional platform test results to libffi-discuss@sourceware.org.
Installing libffi
First you must configure the distribution for your particular system. Go to the directory you wish to build libffi in and run the “configure” program found in the root directory of the libffi source distribution. Note that building libffi requires a C99 compatible compiler.
If you’re building libffi directly from git hosted sources, configure won’t exist yet; run ./autogen.sh first. This will require that you install autoconf, automake and libtool.
You may want to tell configure where to install the libffi library and header files. To do that, use the
--prefix
configure switch. Libffi will install under /usr/local by default.If you want to enable extra run-time debugging checks use the the
--enable-debug
configure switch. This is useful when your program dies mysteriously while using libffi.Another useful configure switch is
--enable-purify-safety
. Using this will add some extra code which will suppress certain warnings when you are using Purify with libffi. Only use this switch when using Purify, as it will slow down the library.If you don’t want to build documentation, use the
--disable-docs
configure switch.It’s also possible to build libffi on Windows platforms with Microsoft’s Visual C++ compiler. In this case, use the msvcc.sh wrapper script during configuration like so:
For 64-bit Windows builds, use
CC="path/to/msvcc.sh -m64"
andCXX="path/to/msvcc.sh -m64"
. You may also need to specify--build
appropriately.It is also possible to build libffi on Windows platforms with the LLVM project’s clang-cl compiler, like below:
When building with MSVC under a MingW environment, you may need to remove the line in configure that sets ‘fix_srcfile_path’ to a ‘cygpath’ command. (‘cygpath’ is not present in MingW, and is not required when using MingW-style paths.)
To build static library for ARM64 with MSVC using visual studio solution, msvc_build folder have aarch64/Ffi_staticLib.sln required header files in aarch64/aarch64_include/
SPARC Solaris builds require the use of the GNU assembler and linker. Point
AS
andLD
environment variables at those tool prior to configuration.For iOS builds, the
libffi.xcodeproj
Xcode project is available.Configure has many other options. Use
configure --help
to see them all.Once configure has finished, type “make”. Note that you must be using GNU make. You can ftp GNU make from ftp.gnu.org:/pub/gnu/make .
To ensure that libffi is working as advertised, type “make check”. This will require that you have DejaGNU installed.
To install the library and header files, type
make install
.History
See the git log for details at http://github.com/libffi/libffi.
Authors & Credits
libffi was originally written by Anthony Green green@moxielogic.com.
The developers of the GNU Compiler Collection project have made innumerable valuable contributions. See the ChangeLog file for details.
Some of the ideas behind libffi were inspired by Gianni Mariani’s free gencall library for Silicon Graphics machines.
The closure mechanism was designed and implemented by Kresten Krab Thorup.
Major processor architecture ports were contributed by the following developers:
Jesper Skov and Andrew Haley both did more than their fair share of stepping through the code and tracking down bugs.
Thanks also to Tom Tromey for bug fixes, documentation and configuration help.
Thanks to Jim Blandy, who provided some useful feedback on the libffi interface.
Andreas Tobler has done a tremendous amount of work on the testsuite.
Alex Oliva solved the executable page problem for SElinux.
The list above is almost certainly incomplete and inaccurate. I’m happy to make corrections or additions upon request.
If you have a problem, or have found a bug, please file an issue on our issue tracker at https://github.com/libffi/libffi/issues.
The author can be reached at green@moxielogic.com.
To subscribe/unsubscribe to our mailing lists, visit: https://sourceware.org/mailman/listinfo/libffi-announce https://sourceware.org/mailman/listinfo/libffi-discuss