Hello Guillem and Simon,
On 2026-01-16 08:51, Guillem Jover wrote:
> On Fri, 2026-01-16 at 17:58:40 +0100, Emanuele Rocca wrote:
> > It seems that dpkg-buildflags erroneously started adding to LDFLAGS
> > -mbranch-protection=standard, while that is not a linker argument.
>
> Hmm, according to #1115292 (commit cdf5f5da0e0cb6f9f4d51e93fd9583bd578c252f)
> this is needed to avoid warnings from the compiler. Was that analysis
> wrong somehow?
I think the analysis was incorrect, yes. The -mbranch-protection flag is
for the compiler only.
Consider the following example.
First we compile two C files with -mbranch-protection=standard and check
that all the required properties are set on the object files:
$ cc -mbranch-protection=standard -c one.c
$ readelf -n one.o | grep Prop
Properties: AArch64 feature: BTI, PAC, GCS
$ cc -mbranch-protection=standard -c two.c
$ readelf -n two.o | grep Prop
Properties: AArch64 feature: BTI, PAC, GCS
Then we use the compiler to link the two object files, *without* passing
any branch-protection flags. The linker checks for the properties in the
object files, finds out that both are annotated, and turns on
PAC/BTI/GCS in the resulting executable too.
$ cc one.o two.o -o program
$ readelf -n program | grep Prop
Properties: AArch64 feature: BTI, PAC, GCS
It may be that packages such as db5.3 are not using CFLAGS *when
compiling*, but the solution is most probably not adding
-mbranch-protection to LDFLAGS. That's a bit like adding -O3 to LDFLAGS
because some programs do not get optimized code.
Thanks,
ema
