Bug #5081
closedsimtrace2 doesn't build for ubuntu 20.04 and 20.10 and debian9
100%
Description
https://build.opensuse.org/package/show/network:osmocom:nightly/simtrace2
In OBS, we have Ubuntu 18.04 - 20.10 enabled. It builds fine for all but 20.04 and 20.10.
As noted in #4687, stack smashing protection is enabled there even when cross compiling for embedded, and causes larger binaries.
[ 473s] [COMPILING ./atmel_softpack_libraries/usb/device/dfu/dfu_driver.c] [ 474s] Memory region Used Size Region Size %age Used [ 474s] rom: 16600 B 16 KB 101.32% [ 474s] ram: 11688 B 48 KB 23.78/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: bin/qmod-dfu-flash.elf section `.text' will not fit in region `rom' [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 474s] /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: region `rom' overflowed by 216 bytes
Related issues
Updated by osmith about 3 years ago
- Related to Bug #4687: simtrace2 dpkg fails to build on Ubuntu 20.04 added
Updated by osmith about 3 years ago
- Subject changed from simtrace2 doesn't build for ubuntu 20.04 and 20.10 to simtrace2 doesn't build for ubuntu 20.04 and 20.10 and debian9
It also started failing on Debian 9, and this in-turn causes the Osmocom-repo-install-debian9 jenkins job to fail.
[ 108s] [COMPILING ./atmel_softpack_libraries/usb/device/dfu/dfu_driver.c] [ 108s] Memory region Used Size Region Size %age Used [ 108s] rom: 16400 B 16 KB 100.10% [ 108s] ram: 11688 B 48 KB 23.78/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 108s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 109s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: bin/qmod-dfu-flash.elf section `.text' will not fit in region `rom' [ 109s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 109s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 109s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 109s] /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: region `rom' overflowed by 16 bytes [ 109s] collect2: error: ld returned 1 exit status
On Debian 10, where it succeeds, it's also pretty close. I guess the newer GCC version used in debian 10 is a bit more efficient.
[ 149s] [COMPILING ./atmel_softpack_libraries/usb/device/dfu/dfu_driver.c] [ 149s] Memory region Used Size Region Size %age Used [ 149s] rom: 16328 B 16 KB 99.66% [ 149s] ram: 11688 B 48 KB 23.78/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 149s] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 149s] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 149s] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes [ 149s] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: warning: changing start of section .stack by 4 bytes
laforge, mschramm: I wonder if we can simply increase the rom region for dfu_driver.c, and take some from, e.g. usb.c:
[ 136s] [COMPILING libcommon/source/usb.c] [ 136s] Memory region Used Size Region Size %age Used [ 136s] rom: 25524 B 240 KB 10.39% [ 136s] ram: 24832 B 48 KB 50.52%Build logs:
Updated by laforge about 3 years ago
On Tue, Apr 06, 2021 at 02:28:56PM +0000, redmine@lists.osmocom.org wrote:
laforge, mschramm: I wonder if we can simply increase the rom region for dfu_driver.c, and take some from, e.g. usb.c:
no, that would render the flash layout incompatible, which is a nightmare
to support, and it would also mean we'd have to maintain builds for old and new
flash layout, and people will brick their devices all over the place.
Updated by Hoernchen about 3 years ago
I've had to prune strings to make it fit a year ago, and as the related ticket points out selectively disabling useless compiler options is apparently not possible, so I don't really see any great options here?
I suppose some dfu code parts can be removed after my patch to reset itself was introduced two months ago.
Updated by osmith about 3 years ago
- Status changed from New to In Progress
- Assignee set to osmith
- % Done changed from 0 to 90
I've disabled the stack protector for qmod-dfu now, this makes the build pass again: https://build.opensuse.org/package/show/home:osmith42/simtrace2
Updated by osmith about 3 years ago
Hoernchen recommended in code review to do this by default for all boards/apps.
Updated by osmith about 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100