msp430: DWARF line info data is bigger than the space remaining in the section

[Forty-Bot]

msp430: DWARF line info data is bigger than the space remaining in the section

[Forty-Bot]

doc/doxygen/src/getting-started.md

RIOT provides a number of examples in the examples/ directory. Every example
has a README that documents its usage and its purpose. You can build them by
typing

make BOARD=samr21-xpro

no mention that you have to either cd or -C to that directory. The way it's written, it's implied that the above command will do something like build all examples.

[maribu]

This seems to be a toolchain issue.

I think I have seen the warning about the debug section being too large when there were other linker issues in addition. I didn't really looked into that, because that never popped up when the real linking error (here undefined reference to main) was fixed. I guess maybe the linker only realizes that the debug section is not flashed (and therefore not limited to a 16 bit space) if all steps before succeed.

Have you tried with BUILD_IN_DOCKER=1? That toolchain is a bit older, sadly. In Alpine Linux we currently ship a GCC 13.1 toolchain that works fine; and a merge request to update to 13.2 is already open. Alpine is relatively lightweight and easy to setup up as a docker container.

If you could provide details about the toolchain I could take a look at what is different to Alpine's and might be able to assist in fixing it.

[Forty-Bot]

If you could provide details about the toolchain I could take a look at what is different to Alpine's and might be able to assist in fixing it.

It's just GCC 13.1. I also tried the releases/gcc-13 branch to the same result. I was able to compile FreeRTOS (and a variety of other projects) fine, so this toolchain is mostly capable.

[maribu]

Did you build the toolchain by hand? If so, what flags did you use to compile it? It would be easier for me to to reproduce if I could build an identical toolchain.

If you haven't build it yourself: Could you post a link where you obtained it?

If FreeRTOS did compile fine it might also be that our build system is badly interacting with that toolchain and we have fix that on our side. But that said, the toolchain in the CI and the Alpine toolchain I am using are both working fine, so the build system does not seem to be that closely tailored to one specific toolchain's oddities.

Btw: It is highly motivating to see people are actually using our MSP430 port :) So thx for opening this issue :)

[Forty-Bot]

For gcc

  ../configure \
    --prefix=/usr \
    --program-prefix=msp430-elf- \
    --target=msp430-elf \
    --host=x86_64-pc-linux-gnu \
    --build=x86_64-pc-linux-gnu \
    --enable-shared \
    --disable-nls \
    --disable-threads \
    --enable-languages=c,c++ \
    --enable-multilib \
    --with-system-zlib \
    --with-local-prefix=/usr/msp430-elf \
    --with-sysroot=/usr/msp430-elf \
    --with-as=/usr/bin/msp430-elf-as \
    --with-ld=/usr/bin/msp430-elf-ld \
    --disable-libgomp \
    --disable-libssp \
    --enable-interwork \
    --enable-addons \
    --enable-lto

for binutils

  ../configure --target=$msp430-elf \
    --prefix=/usr \
    --disable-nls \
    --program-prefix=msp430-elf- \
    --enable-multilib \
    --disable-werror \
    --with-sysroot=/usr/msp430-elf \
    --host=x86_64-pc-linux-gnu \
    --build=x86_64-pc-linux-gnu \
    --disable-shared \
    --enable-lto \
    --with-system-zlib \
    --enable-plugins

[maribu]

OK, the flags look sane to me. I have not tested the resulting toolchain yet.

What version of newlib are you using? And which flags did you use to build that?

[Forty-Bot]

I'm using newlib 4.3.0.20230120

  ../configure \
    --prefix=/usr \
    --target=msp430-elf \
    --disable-newlib-supplied-syscalls \
    --enable-newlib-reent-small \
    --disable-newlib-fseek-optimization \
    --disable-newlib-wide-orient \
    --enable-newlib-nano-formatted-io \
    --disable-newlib-io-float \
    --enable-newlib-nano-malloc \
    --disable-newlib-unbuf-stream-opt \
    --enable-lite-exit \
    --enable-newlib-global-atexit \
    --disable-nls

[maribu]

OK, you will still need the following patch to make syscalls actually work:

By default newlib will disable syscalls for MPS430, which means defunct puts(),
printf(), etc. Since providing those is the main purpose of a standard c lib,
this makes little sense.
This enable syscalls again. With it, MCU operating systems such as RIOT can
provide functioning puts, printf(), read(), write(), etc.
--- a/newlib/configure.host
+++ b/newlib/configure.host
@@ -781,6 +781,9 @@
 	default_newlib_io_long_long="yes"
 	newlib_cflags="${newlib_cflags} -Os -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY"
         ;;
+  msp430*)
+	syscall_dir=syscalls
+    ;;
   nios2*)
 	syscall_dir=
 	newlib_cflags="${newlib_cflags} -DHAVE_RENAME -DHAVE_SYSTEM -DMISSING_SYSCALL_NAMES"

This is taken from Alpine, see https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/newlib

Still, it should link just fine even without the patch. I don't think I will be able to investigate further this weekend. I'll report back as soon as I'm able.

[maribu]

OK, for binutils the flag --target=$msp430-elf should be --target=msp430-elf. For gcc the --with-newlib is missing.

Otherwise, the generated toolchain in a freshly installed Ubuntu docker.io/library/ubuntu:latest container just works:

maribu@b5eaf6fb5878:~/RIOT/examples/default$ make BOARD=olimex-msp430-h1611
/home/maribu/RIOT/examples/default/../../Makefile.include:373: Neither unzip nor 7z is installed.
Building application "default" for "olimex-msp430-h1611" with MCU "msp430".

"make" -C /home/maribu/RIOT/boards/common/init
"make" -C /home/maribu/RIOT/boards/olimex-msp430-h1611
"make" -C /home/maribu/RIOT/core
"make" -C /home/maribu/RIOT/core/lib
"make" -C /home/maribu/RIOT/cpu/msp430
"make" -C /home/maribu/RIOT/cpu/msp430/periph
"make" -C /home/maribu/RIOT/drivers
"make" -C /home/maribu/RIOT/drivers/periph_common
"make" -C /home/maribu/RIOT/drivers/saul
"make" -C /home/maribu/RIOT/drivers/saul/init_devs
"make" -C /home/maribu/RIOT/sys
"make" -C /home/maribu/RIOT/sys/auto_init
"make" -C /home/maribu/RIOT/sys/div
"make" -C /home/maribu/RIOT/sys/fmt
"make" -C /home/maribu/RIOT/sys/isrpipe
"make" -C /home/maribu/RIOT/sys/libc
"make" -C /home/maribu/RIOT/sys/malloc_thread_safe
"make" -C /home/maribu/RIOT/sys/newlib_syscalls_default
"make" -C /home/maribu/RIOT/sys/phydat
"make" -C /home/maribu/RIOT/sys/preprocessor
"make" -C /home/maribu/RIOT/sys/ps
"make" -C /home/maribu/RIOT/sys/saul_reg
"make" -C /home/maribu/RIOT/sys/shell
"make" -C /home/maribu/RIOT/sys/shell/cmds
"make" -C /home/maribu/RIOT/sys/stdio_uart
"make" -C /home/maribu/RIOT/sys/tsrb
/usr/bin/msp430-elf-ld: warning: /home/maribu/RIOT/examples/default/bin/olimex-msp430-h1611/default.elf has a LOAD segment with RWX permissions
   text	  data	   bss	   dec	   hex	filename
  16680	   266	  1142	 18088	  46a8	/home/maribu/RIOT/examples/default/bin/olimex-msp430-h1611/default.elf

So, with those two changes applied the toolchain should work.

[Forty-Bot]

OK, you will still need the following patch to make syscalls actually work:

By default newlib will disable syscalls for MPS430, which means defunct puts(),
printf(), etc. Since providing those is the main purpose of a standard c lib,
this makes little sense.

This is not the case. printf etc. still call write in the default configuration.

OK, for binutils the flag --target=$msp430-elf should be --target=msp430-elf.

This was a typo when copyting things.

For gcc the --with-newlib is missing.

Same error.

[maribu]

Are you sure you do not have two toolchains installed and a different than the one you build is used?

Could you build the toolchain in a clean environment again, e.g. in a chroot / container?

I mean, I started in a clean Ubuntu container, used the same flags and versions and it just worked out of the box. I have no idea how to reproduce the issue now...

[Forty-Bot]

Are you sure you do not have two toolchains installed and a different than the one you build is used?

I am sure.

Could you build the toolchain in a clean environment again, e.g. in a chroot / container?

Just rebuilt GCC and had the same issue.

[maribu]

Just to be sure: By clean environment I mean e.g. a fresh container. So you would have to first build binutils, then gcc, and finally newlib.

[Forty-Bot]

Same result on another computer.

• binutils
• gcc
• newlib

[maribu]

OK, the issue is not the toolchain. In a fresh archlinux container I used pacman -U to install the packages you provided and the toolchain worked out of the box:

make -C examples/default/ BOARD=olimex-msp430-h1611
make: Entering directory '/home/maribu/RIOT/examples/default'
Building application "default" for "olimex-msp430-h1611" with MCU "msp430".

"make" -C /home/maribu/RIOT/boards/common/init
"make" -C /home/maribu/RIOT/boards/olimex-msp430-h1611
"make" -C /home/maribu/RIOT/core
"make" -C /home/maribu/RIOT/core/lib
"make" -C /home/maribu/RIOT/cpu/msp430
"make" -C /home/maribu/RIOT/cpu/msp430/periph
"make" -C /home/maribu/RIOT/drivers
"make" -C /home/maribu/RIOT/drivers/periph_common
"make" -C /home/maribu/RIOT/drivers/saul
"make" -C /home/maribu/RIOT/drivers/saul/init_devs
"make" -C /home/maribu/RIOT/sys
"make" -C /home/maribu/RIOT/sys/auto_init
"make" -C /home/maribu/RIOT/sys/div
"make" -C /home/maribu/RIOT/sys/fmt
"make" -C /home/maribu/RIOT/sys/isrpipe
"make" -C /home/maribu/RIOT/sys/libc
"make" -C /home/maribu/RIOT/sys/malloc_thread_safe
"make" -C /home/maribu/RIOT/sys/newlib_syscalls_default
"make" -C /home/maribu/RIOT/sys/phydat
"make" -C /home/maribu/RIOT/sys/preprocessor
"make" -C /home/maribu/RIOT/sys/ps
"make" -C /home/maribu/RIOT/sys/saul_reg
"make" -C /home/maribu/RIOT/sys/shell
"make" -C /home/maribu/RIOT/sys/shell/cmds
"make" -C /home/maribu/RIOT/sys/stdio_uart
"make" -C /home/maribu/RIOT/sys/tsrb
/usr/bin/msp430-elf-ld: warning: /home/maribu/RIOT/examples/default/bin/olimex-msp430-h1611/default.elf has a LOAD segment with RWX permissions
   text	  data	   bss	   dec	   hex	filename
  16508	   190	  1142	 17840	  45b0	/home/maribu/RIOT/examples/default/bin/olimex-msp430-h1611/default.elf
make: Leaving directory '/home/maribu/RIOT/examples/default'

Could you provide the contents of the folder of the application you want to build and where this is stored relatively to the RIOT git repo?

[Forty-Bot]

As noted in my original issue, I was running

make -C build BOARD=olimex-msp430-h1611 APPLICATION=default -f ../Makefile.include

but apparently I should have been running

make -C examples/default/ BOARD=olimex-msp430-h1611

Neither of these is of course documented. The documented way to build something is

$ make BOARD=samr21-xpro
Welcome to RIOT - The friendly OS for IoT!

You executed 'make' from the base directory.
Usually, you should run 'make' in your application's directory instead.

Please see our Quick Start Guide at:
    https://doc.riot-os.org/getting-started.html
You can ask questions or discuss with other users on our forum:
    https://forum.riot-os.org

Available targets for the RIOT base directory include:
 generate-{board,driver,example,module,pkg,test}
 info-{applications,boards,emulated-boards} info-applications-supported-boards
 print-versions
 clean distclean pkg-clean
 doc doc-{man,latex}

make: *** [Makefile:7: all] Error 1

which of course doesn't work.

[maribu]

The documented way to build something is

Oh, sorry for that. Could you provide a link to the doc that incorrectly states that one is supposted to run make in the root of the repo, rather than in the application folder?

I think fixing that doc would solve this issue then.