Arch Linux User Repository

Greetings, Unfortunately, this is a known issue with the current toolchain [1][2]. The C library, newlib, is not exactly optimized for the MSP430. It is designed to be target independent. A few compromises were made along the way. One of the upstream maintainers of the toolchain recommends compiling with some optimizations which are already found in the PKGBUILD for newlib [3][4], but this proves to be insufficient for some of the smaller targets, like yours. The old mspgcc toolchain, maintained by Peter Bigot and other volunteers, used its own C library, so you never saw these issues. Luckily, possible solutions that may be applicable to your troubles are found in [1] and [2]. It may be kind of hackish at best, but it helps reduce size. Another thing that will shave off about 100 bytes of your code is if you do not let main() return to the runtime environment. __attribute__((noreturn)) void main(void); void main(void) { /* code */ while(1); } /* use -Wno-main to eliminate the ugly compiler warning you get with -Wall */ That being said, all I can say here is: sorry, I wish the situation was better. I really do not know of any other flags/tricks that can help you eliminate things from your code. Providing/overriding some of the symbols exported by libgloss may help, but again, I can not say for sure. Sorry and good luck. Cheers, Orlando. [1] https://e2e.ti.com/support/development_tools/compiler/f/343/t/427058 [2] https://pabigot.github.io/bsp430/msp430elf.html [3] https://people.redhat.com/~dj/msp430/size-optimizations.html [4] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=msp430-elf-newlib

Hi! I've hit a bit of a problem. I have some code that runs on MSP430g2251, which has 2k of ROM. Although this works fine on my old box with mspgcc 4.6.3 20120301, with this version I've got around 600B more code, which turns out to be fatal :-) The problem is, that from stdlib (or somewhere else, I didn't really track it down) gcc links in some junk I don't really use or need, and the linker should be able to detele it. However, it does not do so. My current compile commands are: msp430-elf-gcc -std=c99 -Os -Wall -g -mmcu=msp430g2231 -Ilib -I. -ffunction-sections -Wl,--gc-sections -flto -fdata-sections -c main.c -o main.o msp430-elf-gcc -std=c99 -Os -Wall -g -mmcu=msp430g2231 -Ilib -I. -ffunction-sections -Wl,--gc-sections -flto -fdata-sections -o main.elf main.o -flto doesn't change a thing. The section gc spared me around 100B (the "junk" was around 700B before that). It seems however, that this code doesn't have it's own sections and can't be garbage-collected. My guess is it comes from a hand-written assembly. Any ideans on how to get rid of it? Thanks! Here are some symbols that take up the space. Some of them might be useful, but most of them are not. This was generated with an empty main.c with single empty function void main() {}. 0000f80c <__crt0_start>: 0000f810 <__crt0_movedata>: 0000f824 <__crt0_call_init_then_main>: 0000f832 <_msp430_run_init_array>: 0000f840 <_msp430_run_preinit_array>: 0000f84e <_msp430_run_fini_array>: 0000f85e <_msp430_run_array>: 0000f86c <_msp430_run_done>: 0000f86e <deregister_tm_clones>: 0000f88c <register_tm_clones>: 0000f8ba <__do_global_dtors_aux>: 0000f90a <frame_dummy>: 0000f938 <main>: 0000f93a <__mspabi_func_epilog_7>: 0000f93c <__mspabi_func_epilog_6>: [...] 0000f94a <__mspabi_srli_15>: 0000f94e <__mspabi_srli_14>: [...] 0000f994 <__mspabi_srll_15>: 0000f99a <__mspabi_srll_14>: [...] 0000f9fe <__do_global_ctors_aux>: 0000fa1e <memmove>:

Greetings, Thank you for reporting the issue. The nosys.specs file used to be part of the msp430-elf-newlib package. However, this file was removed when the package was updated to version 2.3.0.20160104. The patch that removed it is here [1]. You can see the commit message in the PKGBUILD here [2]. You may still be able to link in libnosys.a by explicitly telling the linker to use that file using the parameters: -lcrt -lnosys at the end of your linking command. Thank you. Cheers, Orlando. [1] https://sourceware.org/ml/newlib/2015/msg00926.html [2] https://aur.archlinux.org/cgit/aur.git/commit/?h=msp430-elf-newlib&id=d28c840e863a3d485c99dcc763d9ee0dbdc2ebdc

Hi, thank you for maintaining this package! I am experiencing the same problem that kl1278 described on 10/22/2015. I would also prefer to use libnosys.a over providing _exit() in my own code. Unfortunately, the file nosys.specs does not exist in my system. Which package would contain this file? Could I generate it myself? Thank you in advance!

This package works perfectly. Thank you!

Greetings, Thank you for reporting this. The problem here is twofold. First, you have a [non-critical] error with libbfd in binutils. This is the one dealing with the dwarf errors message. It is likely due to linker relaxations, upstream should be looking into it as we speak [or so I hope, I have not heard back from them in a while]. The second problem is a linking error, this one is fatal. Since you are returning from main, the linker attempts to add code necessary for "program termination", which boils down to returning control to the C runtime which calls the exit() function. The problem here is that newlib implements this with a call to _exit(), as you may have noticed from your linker error. By default, newlib provides an implementation for this function but it is not linked in by default [1][2]. The reasoning behind this was explained in the mspgcc mailing list [3]. As such, to "fix" the problem you can do one of two things: 1) Provide your own implementation of _exit() in your program. The following is an example implementation: void _exit(int i) __attribute__((naked)); void _exit(int i) { /* turn off CPU and enable interrupts */ __bis_SR_register(CPUOFF | GIE); /* compiler will warn about noreturn function returning */ /* if the following line is not present, however, we never get here */ /* it can safely be omitted */ while(1); } 2) Use the provided implementation newlib by linking in libnosys.a to your program using the provided specs file by passing -specs=nosys.specs to the compiler. Either one of these will solve both of your problems. One tip though, when programming, much like in avr-libc, there is a "master" header file for MSP430, you should use that instead: #include "msp430f2272.h" /* do not do this */ #include <msp430.h> /* do this instead */ The compiler will define the necessary symbols and include the proper header file based on the -mmcu parameter that it is given. Cheers, Orlando. [1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01809.html [2] https://sourceware.org/ml/newlib/2014/msg00465.html [3] https://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12104.html

I just found this error while building a program. I've reduced the error to this minimal example. build command: msp430-elf-gcc -O0 -mmcu=msp430f2272 ./main.c -o test.elf ========================================== #include "msp430f2272.h" int main(void) { WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer for (;;) {} } no error while linking ========================================== #include "msp430f2272.h" int main(void) { WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer return 0; } when building, this error pops up: /usr/bin/msp430-elf-ld: Dwarf Error: Line info data is bigger (0xfffffffc) than the section (0x46) /usr/lib/gcc/msp430-elf/5.2.0/../../../../msp430-elf/lib/430/libcrt.a(crt_callexit.o): In function `__crt0_call_exit': (.crt_0800call_exit+0x2): undefined reference to `_exit' collect2: error: ld returned 1 exit status

Greetings, With the help of the fellows at the GDB IRC channel, we have managed to figure out the root of the issue. It seems that GCC is either building the DWARF information incorrectly, or GDB parsing it wrong: Compilation Unit @ offset 0xb2: Length: 0x82 (32-bit) Version: 4 Abbrev Offset: 0x12 Pointer Size: 4 GDB expects the Pointer Size field to be 2 instead of 4 and does not populate the corresponding compunit_symtab struct. The reason readelf is capable of reading the line number information is because it uses a different algorithm than gdb does. At this point we are not sure who is right and a bug has been filed with GDB [1]. In the mean time, I have provided a PKGBUILD with a patch for GDB which makes it use the same algorithm readelf uses to load line numbers. I have tested this patch against an MSP430f2013 [small memory model] and I am able to properly trace through main(). I have only compiled against a large memory model with symbols and line numbers being read, but I am unable to physically test it, as I do not currently have with me any cores with me that support the MSP430X instruction set. Thank you for your patience. I will report back with a proper fix once I get a response from the bugtracker. Cheers, Orlando. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19033

Greetings, I have managed to replicate your issue on my end. It seems like there is a discrepancy with the format GCC is issuing the debug symbols and how GDB is attempting to read them. Amusingly, I am unable to find anything in the changelogs that would point to this happening. I will take this to upstream for further guidance and report back whatever I find. In the mean time, I have updated the PKGBUILD for newlib to include debug symbols. I am thinking of eliminating -ffunction-sections and -fdata-sections from the target options. If my understanding of the gcc documentation is correct, they can interfere with debug symbols [1]. This change, however, does not fix the problem at hand. Thank you for your patience. Cheers, Orlando. [1] https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html

Geetings, The minimal example: #include <msp430.h> volatile unsigned int i; int main(void) { WDTCTL = WDTPW + WDTHOLD; P1DIR |= 0x01; for (;;) { P1OUT ^= 0x01; i = 50000; do (i--); while (i != 0); } } compiled with: msp430-elf-gcc -g -O0 -mmcu=msp430f2272 ./main.c -o test.elf I'm trying to debug it with mspdebug 0.23, and msp430-elf-gdb version 7.10 If I specify '-gstabs' it works. '-gdwarf' Doesn't. Thank you.