- Package:
- libffi-dev
- Source:
- libffi-dev
- Description:
- Foreign Function Interface library (development files)
- Submitter:
- Jianfeng Liu
- Date:
- 2026-09-02 07:29:02 UTC
- Severity:
- normal
- Tags:
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
isn't that something that should be done upstream for that architecture?
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
Control: tags -1 - patch if there are performance regressions, then you should not build the shared library with this option as well. so the proper solution is to build the libffi_pic.a file from a second build on loong64. please update the patch. so, again the same regressions here, building everything with the medium model.
Control: tags -1 - patch if there are performance regressions, then you should not build the shared library with this option as well. so the proper solution is to build the libffi_pic.a file from a second build on loong64. please update the patch. so, again the same regressions here, building everything with the medium model.
Hi, Now gcc 16 has made medium as their default mcmodel since v16.2.0: https://github.com/gcc-mirror/gcc/commit/cc3ade6da5c4b7d55425a15f25325ae84ef945a2 The commiter Xi Ruoyao said in the commit msg: I also had some concern about a potential performance regression caused by the conservative nature of the relaxation process, but when I tested this patch it turned out the relaxation is powerful enough to eliminate all the pcaddu18i instructions in cc1plus and libstdc++.so. So I think building dynamic libraries with medium mcmodel should be fine now. Best regards, Jianfeng
Hi, Now gcc 16 has made medium as their default mcmodel since v16.2.0: https://github.com/gcc-mirror/gcc/commit/cc3ade6da5c4b7d55425a15f25325ae84ef945a2 The commiter Xi Ruoyao said in the commit msg: I also had some concern about a potential performance regression caused by the conservative nature of the relaxation process, but when I tested this patch it turned out the relaxation is powerful enough to eliminate all the pcaddu18i instructions in cc1plus and libstdc++.so. So I think building dynamic libraries with medium mcmodel should be fine now. Best regards, Jianfeng
Hi, Now gcc 16 has made medium as their default mcmodel since v16.2.0: https://github.com/gcc-mirror/gcc/commit/cc3ade6da5c4b7d55425a15f25325ae84ef945a2 The commiter Xi Ruoyao said in the commit msg: I also had some concern about a potential performance regression caused by the conservative nature of the relaxation process, but when I tested this patch it turned out the relaxation is powerful enough to eliminate all the pcaddu18i instructions in cc1plus and libstdc++.so. So I think building dynamic libraries with medium mcmodel should be fine now. Best regards, Jianfeng
ok, then just closing the issue. once gcc-defaults migrates to testing, please schedule binNMUs for all relevant packages, that need a no-change rebuild.
ok, then just closing the issue. once gcc-defaults migrates to testing, please schedule binNMUs for all relevant packages, that need a no-change rebuild.