Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

[Keith Packard]

> One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
> exclude the LTO flags specifically so that they don't leak into the target
> builds.  Another thought I had was to use the dpkg-buildflags for armhf as a
> target architecture, since there could be other per-arch flags in the future
> that cause further problems.  I've tried the latter approach in the attached
> patch, which fixes the problem of lto being incorrectly used for the
> arm-none-eabi target.  I've verified that the resulting libstdc++ is usable
> again with this change.

Yeah, neither of these is really appropriate; we're not building Debian
code here. As 'rules' already sets the complete CFLAGS and CXXFLAGS
values save the necessary flags for a reproducible build, how about I
just add `-ffile-prefix-map=$(TOP_DIR)=.` manually and stop using
/usr/share/dpkg/buildflags.mk?

@@ -10,7 +10,6 @@ MULTILIB_LIST="--with-multilib-list=rmprofile"
 GCC_PACKAGE=gcc-arm-none-eabi
 
 include /usr/share/dpkg/pkg-info.mk
-include /usr/share/dpkg/buildflags.mk
 
 SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
 DVERSION := $(SVERSION)+$(DEB_VERSION)
@@ -29,6 +28,9 @@ 
BUILD_PICOLIBC_RELEASE_DIR=$(TOP_DIR)/build_picolibc_release/libstdc++
 PNEWLIB=libstdc\+\+-arm-none-eabi-newlib
 PPICOLIBC=libstdc\+\+-arm-none-eabi-picolibc
 
+CFLAGS := -ffile-prefix-map=$(TOP_DIR)=. -Wformat -Werror=format-security
+CXXFLAGS := $(CFLAGS)
+
 BUILDFLAGS=CFLAGS="$(CFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
CXXFLAGS="$(CXXFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_NANO=CFLAGS="$(CFLAGS) -g -Os -ffunction-sections -fdata-sections 
-fno-exceptions" CXXFLAGS="$(CXXFLAGS) -g -Os -ffunction-sections 
-fdata-sections -fno-exceptions" LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_PICOLIBC=CFLAGS="--specs=picolibc.specs $(CFLAGS) -g -Os 
-ffunction-sections -fdata-sections" CXXFLAGS="--specs=picolibcpp.specs 
$(CXXFLAGS) -g -Os -ffunction-sections -fdata-sections" 
LDFLAGS="--specs=picolibc.specs $(LDFLAGS)"


-- 
-keith


signature.asc
Description: PGP signature

Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

[Steve Langasek]

Package: libstdc++-arm-none-eabi
Version: 20
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Keith,

libstdc++-arm-none-eabi has been stuck in Ubuntu since version 18, with all
related autopkgtests failing.  Tracking this down, I find that the problem
is g++ is trying to call lto1:

[...]
arm-none-eabi-g++ multiram.cc ../../startup/startup_ARMCM0.S -mthumb 
-mcpu=cortex-m0 -D__NO_SYSTEM_INIT -Os -flto -ffunction-sections 
-fdata-sections -D__STARTUP_COPY_MULTIPLE -D__STARTUP_CLEAR_BSS_MULTIPLE 
-fno-exceptions --specs=nano.specs --specs=rdimon.specs -L. -L../../ldscripts 
-T multi-ram.ld -Wl,--gc-sections -Wl,-Map=multiram.map -o multiram-CM0.axf
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: arm-none-eabi-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: error: 
lto-wrapper failed
[...]

  
(https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/b/binutils-arm-none-eabi/20220621_090851_aa0ae@/log.gz)

The issue is that Ubuntu uses LTO by default *on amd64*, and the change to
include the output of dpkg-buildflags somehow has the effect that LTO is now
being used for the target.

This does not currently cause a problem in Debian because Debian is not
doing LTO by default; but there is discussion about changing this, so this
will likely become a problem in Debian as well within the current release
cycle.

One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
exclude the LTO flags specifically so that they don't leak into the target
builds.  Another thought I had was to use the dpkg-buildflags for armhf as a
target architecture, since there could be other per-arch flags in the future
that cause further problems.  I've tried the latter approach in the attached
patch, which fixes the problem of lto being incorrectly used for the
arm-none-eabi target.  I've verified that the resulting libstdc++ is usable
again with this change.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libstdc++-arm-none-eabi-20/debian/rules 
libstdc++-arm-none-eabi-20ubuntu1/debian/rules
--- libstdc++-arm-none-eabi-20/debian/rules 2022-03-25 15:22:56.0 
-0700
+++ libstdc++-arm-none-eabi-20ubuntu1/debian/rules  2022-07-08 
12:25:35.0 -0700
@@ -12,6 +12,9 @@
 include /usr/share/dpkg/pkg-info.mk
 include /usr/share/dpkg/buildflags.mk
 
+CFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CFLAGS)
+CXXFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CXXFLAGS)
+
 SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
 DVERSION := $(SVERSION)+$(DEB_VERSION)
 UVERSION := $(shell echo $(DVERSION) | cut -d- -f1)