#1107859 libffi-dev: Can't link libffi_pic.a to large binaries like chromium on loong64

Package:
libffi-dev
Source:
libffi-dev
Description:
Foreign Function Interface library (development files)
Submitter:
Jianfeng Liu
Date:
2025-06-16 12:51:01 UTC
Severity:
normal
Tags:
#1107859#5
Date:
2025-06-16 02:54:28 UTC
From:
To:
Chromium is linking libffi staticly. While on LoongArch64 platform the
default code model

provides 256MiB PC-relative addressing space[1], which is not enough for
chromium.

I will get following errors like:


ld.lld-19: error:
/lib/loongarch64-linux-gnu/libffi_pic.a(prep_cif.o):(function
ffi_prep_cif_core: .text+0x2b8): relocation R_LARCH_B26 out of range:
157436696 is not in [-134217728, 134217727]; references 'abort'


After recompiling libffi with code model medium, chromium can get linked
fine.


Here is my patch setting medium code model:


diff --git a/debian/rules b/debian/rules
index 87e4467..7ad92a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,13 @@ CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
  CFLAGS   = $(shell dpkg-buildflags --get CFLAGS)
  LDFLAGS  = $(shell dpkg-buildflags --get LDFLAGS)

+# This will enable linking libffi staticly with large binaries like
chromium.
+# For more details, see:
+#
https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc#code_models
+ifeq (loong64,$(DEB_HOST_ARCH))
+CFLAGS += -mcmodel=medium
+endif
+
  ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
    with_check = yes
  else

#1107859#10
Date:
2025-06-16 07:01:48 UTC
From:
To:
isn't that something that should be done upstream for that architecture?
#1107859#17
Date:
2025-06-16 12:49:48 UTC
From:
To:
Hi,
- normal, the default one providing 256MiB PC-relative memory space.
- medium, providing 256GiB PC-relative memory space.
- extreme, providing full 64-bit memory space

And from the doc[1], wider addressing range requires more instructions and
brings higher overhead. The performance and size of an application can
benefit from a code model that does not overestimate the memory space
accessed by the code.  So I think the default normal model should be fine
for common use. If upstream compiler makes medium by default, that may harm
performance and size when the binary size is not that large like chromium.
So we have to decide which code model to use on each library. libffi is a
library which is set statically linked by chromium, so we have to build
libffi with medium code model.

There is also libc++.a having similar issue[2] when linking chromium on
loong64, so I have created a MR[3] at llvm.

[1]
https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc#code-models
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107858
[3]
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/172

Best regards,
Jianfeng