[Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

[Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

[Ben Wolsieffer]

This series re-introduces support for the FDPIC binary format, which is
now usable on ARM.

The first patch reverts the removal of general FDPIC support, while the
second adds support for FDPIC specifically on ARM.

Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Ben Wolsieffer (2):
  Revert "arch: drop now useless support for FDPIC"
  arch/arm: add support for FDPIC

 arch/Config.in           | 15 +++++++++++++++
 package/Makefile.in      | 30 +++++++++++++++++++++---------
 package/uclibc/uclibc.mk |  8 ++++++++
 3 files changed, 44 insertions(+), 9 deletions(-)

-- 
2.37.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/2] Revert "arch: drop now useless support for FDPIC"

[Ben Wolsieffer]

This reverts commit 58dcd28dfbed481becb822b009583a63efbc6ffa.

ARM supports FDPIC, so this code is needed once again.

Signed-off-by: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
---
 arch/Config.in           | 14 ++++++++++++++
 package/uclibc/uclibc.mk |  8 ++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/Config.in b/arch/Config.in
index 1c0c400a98..c5d481b9e5 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -12,6 +12,9 @@ config BR2_SOFT_FLOAT
 config BR2_USE_MMU
 	bool
 
+config BR2_ARCH_HAS_FDPIC_SUPPORT
+	bool
+
 choice
 	prompt "Target Architecture"
 	default BR2_i386
@@ -418,6 +421,7 @@ endif
 choice
 	prompt "Target Binary Format"
 	default BR2_BINFMT_ELF if BR2_USE_MMU
+	default BR2_BINFMT_FDPIC if BR2_ARCH_HAS_FDPIC_SUPPORT
 	default BR2_BINFMT_FLAT
 
 config BR2_BINFMT_ELF
@@ -429,6 +433,16 @@ config BR2_BINFMT_ELF
 	  and executables used across different architectures and
 	  operating systems.
 
+config BR2_BINFMT_FDPIC
+	bool "FDPIC"
+	depends on BR2_ARCH_HAS_FDPIC_SUPPORT
+	select BR2_BINFMT_SUPPORTS_SHARED
+	help
+	  ELF FDPIC binaries are based on ELF, but allow the individual
+	  load segments of a binary to be located in memory
+	  independently of each other. This makes this format ideal for
+	  use in environments where no MMU is available.
+
 config BR2_BINFMT_FLAT
 	bool "FLAT"
 	depends on !BR2_USE_MMU
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index 0e17a8e65d..ff98a05c16 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -56,6 +56,14 @@ UCLIBC_LOCALES = \
 endif
 
 # noMMU binary formats
+ifeq ($(BR2_BINFMT_FDPIC),y)
+define UCLIBC_BINFMT_CONFIG
+	$(call KCONFIG_DISABLE_OPT,UCLIBC_FORMAT_FLAT,$(@D)/.config)
+	$(call KCONFIG_DISABLE_OPT,UCLIBC_FORMAT_FLAT_SEP_DATA,$(@D)/.config)
+	$(call KCONFIG_DISABLE_OPT,UCLIBC_FORMAT_SHARED_FLAT,$(@D)/.config)
+	$(call KCONFIG_ENABLE_OPT,UCLIBC_FORMAT_FDPIC_ELF,$(@D)/.config)
+endef
+endif
 ifeq ($(BR2_BINFMT_FLAT_ONE),y)
 define UCLIBC_BINFMT_CONFIG
 	$(call KCONFIG_ENABLE_OPT,UCLIBC_FORMAT_FLAT)
-- 
2.37.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] arch/arm: add support for FDPIC

[Ben Wolsieffer]

Linux on ARM supports FDPIC binaries intended for use on no-MMU systems.
This patch enables support for building a toolchain that produces FDPIC
binaries.

Unfortunately, the target name for an FDPIC toolchain is a bit
idiosyncratic and must be arm-<vendor>-uclinuxfdpiceabi. This requires a
few special cases in the target construction code, since there is no
separate TARGET_OS field.

According to the kernel help for CONFIG_BINFMT_ELF_FDPIC, "It is also
possible to run FDPIC ELF binaries on MMU linux," so FDPIC support is
available on all ARM platforms, not just no-MMU.

Signed-off-by: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
---
 arch/Config.in      |  1 +
 package/Makefile.in | 30 +++++++++++++++++++++---------
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/Config.in b/arch/Config.in
index c5d481b9e5..8dab58cf04 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -39,6 +39,7 @@ config BR2_arceb
 
 config BR2_arm
 	bool "ARM (little endian)"
+	select BR2_ARCH_HAS_FDPIC_SUPPORT
 	# MMU support is set by the subarchitecture file, arch/Config.in.arm
 	help
 	  ARM is a 32-bit reduced instruction set computer (RISC)
diff --git a/package/Makefile.in b/package/Makefile.in
index ff60f85092..d75f620d82 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -36,18 +36,21 @@ $(error BR2_TOOLCHAIN_BUILDROOT_VENDOR cannot be 'unknown'. \
 	It might be confused with the native toolchain)
 endif
 
-# Compute GNU_TARGET_NAME
-GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
-
 # FLAT binary format needs uclinux, except RISC-V 64-bits which needs
 # the regular linux name.
 ifeq ($(BR2_BINFMT_FLAT):$(BR2_RISCV_64),y:)
 TARGET_OS = uclinux
+# FDPIC binary format requires no OS field in target
+else ifeq ($(BR2_BINFMT_FDPIC),y)
+TARGET_OS =
 else
 TARGET_OS = linux
 endif
 
-ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
+# FDPIC suffix must be -uclinuxfdpiceabi
+ifeq ($(BR2_BINFMT_FDPIC),y)
+LIBC = uclinux
+else ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
 LIBC = uclibc
 else ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
 LIBC = musl
@@ -59,12 +62,14 @@ else
 $(error No C library enabled, this is not possible.)
 endif
 
-# The ABI suffix is a bit special on ARM, as it needs to be
-# -uclibcgnueabi for uClibc EABI, and -gnueabi for glibc EABI.
-# This means that the LIBC and ABI aren't strictly orthogonal,
-# which explains why we need the test on LIBC below.
+# The ABI suffix is a bit special on ARM, as it needs to be -uclibcgnueabi
+# for uClibc EABI, -gnueabi for glibc EABI and -uclinuxfdpiceabi if FDPIC is
+# used. This means that the LIBC and ABI aren't strictly orthogonal, which
+# explains why we need the test on LIBC below.
 ifeq ($(BR2_arm)$(BR2_armeb),y)
-ifeq ($(LIBC),uclibc)
+ifeq ($(BR2_BINFMT_FDPIC),y)
+ABI = fdpiceabi
+else ifeq ($(LIBC),uclibc)
 ABI = gnueabi
 else
 ABI = eabi
@@ -90,6 +95,13 @@ TARGET_ABI += -mabi=spe -mfloat-gprs=double -Wa,-me500mc
 endif
 endif
 
+# Compute GNU_TARGET_NAME
+ifeq ($(TARGET_OS),)
+GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(LIBC)$(ABI)
+else
+GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
+endif
+
 # Use longcalls option for Xtensa globally.
 # The 'longcalls' option allows calls across a greater range of addresses,
 # and is required for some packages. While this option can degrade both
-- 
2.37.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] arch/arm: add support for FDPIC

[Arnout Vandecappelle]

On 02/08/2022 15:30, Ben Wolsieffer wrote:
> Linux on ARM supports FDPIC binaries intended for use on no-MMU systems.
> This patch enables support for building a toolchain that produces FDPIC
> binaries.
> 
> Unfortunately, the target name for an FDPIC toolchain is a bit
> idiosyncratic and must be arm-<vendor>-uclinuxfdpiceabi. This requires a
> few special cases in the target construction code, since there is no
> separate TARGET_OS field.
> 
> According to the kernel help for CONFIG_BINFMT_ELF_FDPIC, "It is also
> possible to run FDPIC ELF binaries on MMU linux," so FDPIC support is
> available on all ARM platforms, not just no-MMU.
> 
> Signed-off-by: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
> ---
>   arch/Config.in      |  1 +
>   package/Makefile.in | 30 +++++++++++++++++++++---------
>   2 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/Config.in b/arch/Config.in
> index c5d481b9e5..8dab58cf04 100644
> --- a/arch/Config.in
> +++ b/arch/Config.in
> @@ -39,6 +39,7 @@ config BR2_arceb
>   
>   config BR2_arm
>   	bool "ARM (little endian)"
> +	select BR2_ARCH_HAS_FDPIC_SUPPORT
>   	# MMU support is set by the subarchitecture file, arch/Config.in.arm
>   	help
>   	  ARM is a 32-bit reduced instruction set computer (RISC)
> diff --git a/package/Makefile.in b/package/Makefile.in
> index ff60f85092..d75f620d82 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -36,18 +36,21 @@ $(error BR2_TOOLCHAIN_BUILDROOT_VENDOR cannot be 'unknown'. \
>   	It might be confused with the native toolchain)
>   endif
>   
> -# Compute GNU_TARGET_NAME
> -GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
> -
>   # FLAT binary format needs uclinux, except RISC-V 64-bits which needs
>   # the regular linux name.
>   ifeq ($(BR2_BINFMT_FLAT):$(BR2_RISCV_64),y:)
>   TARGET_OS = uclinux
> +# FDPIC binary format requires no OS field in target
> +else ifeq ($(BR2_BINFMT_FDPIC),y)
> +TARGET_OS =
>   else
>   TARGET_OS = linux
>   endif
>   
> -ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
> +# FDPIC suffix must be -uclinuxfdpiceabi
> +ifeq ($(BR2_BINFMT_FDPIC),y)
> +LIBC = uclinux
> +else ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
>   LIBC = uclibc
>   else ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
>   LIBC = musl
> @@ -59,12 +62,14 @@ else
>   $(error No C library enabled, this is not possible.)
>   endif
>   
> -# The ABI suffix is a bit special on ARM, as it needs to be
> -# -uclibcgnueabi for uClibc EABI, and -gnueabi for glibc EABI.
> -# This means that the LIBC and ABI aren't strictly orthogonal,
> -# which explains why we need the test on LIBC below.
> +# The ABI suffix is a bit special on ARM, as it needs to be -uclibcgnueabi
> +# for uClibc EABI, -gnueabi for glibc EABI and -uclinuxfdpiceabi if FDPIC is
> +# used. This means that the LIBC and ABI aren't strictly orthogonal, which
> +# explains why we need the test on LIBC below.
>   ifeq ($(BR2_arm)$(BR2_armeb),y)
> -ifeq ($(LIBC),uclibc)
> +ifeq ($(BR2_BINFMT_FDPIC),y)
> +ABI = fdpiceabi
> +else ifeq ($(LIBC),uclibc)
>   ABI = gnueabi
>   else
>   ABI = eabi
> @@ -90,6 +95,13 @@ TARGET_ABI += -mabi=spe -mfloat-gprs=double -Wa,-me500mc
>   endif
>   endif
>   
> +# Compute GNU_TARGET_NAME
> +ifeq ($(TARGET_OS),)
> +GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(LIBC)$(ABI)
> +else
> +GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
> +endif

  I think all the special-casing for TARGET_OS, LIBC and ABI are way too 
complicated. None of these are used anywhere else (except LIBC which is also 
used in rust.mk - but Rust won't support FDPIC ever I think). So I think you 
should just put the special-casing here in GNU_TARGET_NAME itself:

# The tuple for FDPIC on ARM is very special: it doesn't have the OS part, and
# it must end with -uclinuxfdpiceabi
ifeq ($(BR2_BINFMT_FDPIC),y)
GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-uclinuxfdpiceabi
else
GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
endif

  If we ever add other architectures with FDPIC (RISC-V is a likely candidate), 
we may revisit that again, but for now this is sufficient.

  Regards,
  Arnout

> +
>   # Use longcalls option for Xtensa globally.
>   # The 'longcalls' option allows calls across a greater range of addresses,
>   # and is required for some packages. While this option can degrade both
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

[Ben Wolsieffer]

On Tue, Aug 09, 2022 at 12:26:14PM +0100, Vladimir Murzin wrote:
> 
> You might also want to allow uClibc to use NPTL thread library instead
> of old(-sh) LinuxThreads with something like
> 
> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
> index ba8b5885ec..30a154531a 100644
> --- a/package/uclibc/Config.in
> +++ b/package/uclibc/Config.in
> @@ -76,7 +76,7 @@ choice
>  
>  config BR2_PTHREADS_NATIVE
>         bool "Native POSIX Threading (NPTL)"
> -       depends on BR2_USE_MMU
> +       depends on BR2_USE_MMU || BR2_BINFMT_FDPIC
>         select BR2_TOOLCHAIN_HAS_THREADS
>         select BR2_TOOLCHAIN_HAS_THREADS_NPTL
>  

You mean I could have just used NPTL and not wasted hours fighting
LinuxThreads...

I'm not sure how I missed this before, since I immediately found the
relevant patches when I searched for them now.

I've been playing around with NPTL and FDPIC and it doesn't quite work
perfectly out of the box. Static libraries (linked into a dynamic
executable) crash when attempting to use TLS. In addition, the reason
static libraries are even being used is because libtool doesn't recognize
the target name and therefore thinks it can't build shared libaries.

There was a patch [1] submitted a few years ago to add the target to
libtool, but it looks like it was ignored. Unfortunately, we can't just
apply it in Buildroot, unless we want to run autoreconf on every
package. I'm working around this locally with a hacky hook to patch
configure scripts, but I'm not sure it is appropriate to upstream.

Although the situation is not ideal, things basically work with
LinuxThreads and the libtool issue, so I'd prefer to get this patch set
finished without expanding the scope.

Thanks, Ben

[1] https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg00000.html
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

[Arnout Vandecappelle]

On 11/08/2022 23:37, Ben Wolsieffer wrote:
> On Tue, Aug 09, 2022 at 12:26:14PM +0100, Vladimir Murzin wrote:
>>
>> You might also want to allow uClibc to use NPTL thread library instead
>> of old(-sh) LinuxThreads with something like
>>
>> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
>> index ba8b5885ec..30a154531a 100644
>> --- a/package/uclibc/Config.in
>> +++ b/package/uclibc/Config.in
>> @@ -76,7 +76,7 @@ choice
>>   
>>   config BR2_PTHREADS_NATIVE
>>          bool "Native POSIX Threading (NPTL)"
>> -       depends on BR2_USE_MMU
>> +       depends on BR2_USE_MMU || BR2_BINFMT_FDPIC
>>          select BR2_TOOLCHAIN_HAS_THREADS
>>          select BR2_TOOLCHAIN_HAS_THREADS_NPTL
>>   
> 
> You mean I could have just used NPTL and not wasted hours fighting
> LinuxThreads...
> 
> I'm not sure how I missed this before, since I immediately found the
> relevant patches when I searched for them now.
> 
> I've been playing around with NPTL and FDPIC and it doesn't quite work
> perfectly out of the box. Static libraries (linked into a dynamic
> executable) crash when attempting to use TLS. In addition, the reason
> static libraries are even being used is because libtool doesn't recognize
> the target name and therefore thinks it can't build shared libaries.
> 
> There was a patch [1] submitted a few years ago to add the target to
> libtool, but it looks like it was ignored. Unfortunately, we can't just
> apply it in Buildroot, unless we want to run autoreconf on every
> package. I'm working around this locally with a hacky hook to patch
> configure scripts, but I'm not sure it is appropriate to upstream.

  This problem exists for a number of architectures. For that reason, we have a 
workaround: the LIBTOOL_PATCH_HOOK [1]. For any autotools package, we search for 
ltmain.sh files in the source, parse out the libtool version from it, and apply 
the appropriate patch from support/libtool/

  In other words, the solution is to extend the patches in support/libtool/ with 
the missing architecture.


  Regards,
  Arnout

[1] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-autotools.mk#L60


> 
> Although the situation is not ideal, things basically work with
> LinuxThreads and the libtool issue, so I'd prefer to get this patch set
> finished without expanding the scope.
> 
> Thanks, Ben
> 
> [1] https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg00000.html
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

[Ben Wolsieffer]

On Sun, Aug 14, 2022 at 11:55:37PM +0200, Arnout Vandecappelle wrote:
> > 
> > I've been playing around with NPTL and FDPIC and it doesn't quite work
> > perfectly out of the box. Static libraries (linked into a dynamic
> > executable) crash when attempting to use TLS. In addition, the reason
> > static libraries are even being used is because libtool doesn't recognize
> > the target name and therefore thinks it can't build shared libaries.
> > 
> > There was a patch [1] submitted a few years ago to add the target to
> > libtool, but it looks like it was ignored. Unfortunately, we can't just
> > apply it in Buildroot, unless we want to run autoreconf on every
> > package. I'm working around this locally with a hacky hook to patch
> > configure scripts, but I'm not sure it is appropriate to upstream.
> 
>  This problem exists for a number of architectures. For that reason, we have
> a workaround: the LIBTOOL_PATCH_HOOK [1]. For any autotools package, we
> search for ltmain.sh files in the source, parse out the libtool version from
> it, and apply the appropriate patch from support/libtool/
> 
>  In other words, the solution is to extend the patches in support/libtool/
> with the missing architecture.
> 

In this case, the relevant file is libtool.m4, and this file gets
expanded into configure. Therefore, we either need a patch for configure
for each libtool version (like LIBTOOL_PATCH_HOOK), or use sed to patch
any matches against "linux*". I've been using the sed solution, which is
far simpler, but I'm not sure it is clean enough to be included upstream.

Ben

> 
>  Regards,
>  Arnout
> 
> [1] https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-autotools.mk#L60
> 
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot