Package Details: msp430-elf-gcc 11.2.0-2

Git Clone URL: https://aur.archlinux.org/msp430-elf-gcc.git (read-only, click to copy)
Package Base: msp430-elf-gcc
Description: The GNU Compiler Collection for the msp430-elf target.
Upstream URL: http://gcc.gnu.org
Licenses: GPL, LGPL
Conflicts: msp430-elf-gcc-stage1
Provides: msp430-elf-gcc-stage1
Replaces: msp430-elf-gcc-stage1
Submitter: vonPalitroque
Maintainer: vonPalitroque
Last Packager: vonPalitroque
Votes: 13
Popularity: 0.000000
First Submitted: 2015-09-19 18:38 (UTC)
Last Updated: 2022-02-16 22:02 (UTC)

Latest Comments

kamnxt commented on 2021-10-25 09:22 (UTC) (edited on 2021-10-25 09:40 (UTC) by kamnxt)

The isl source has been shut down (https://groups.google.com/g/isl-development/c/JGaMo2VUu_8?pli=1), so the package doesn't build anymore. Seems to work fine using libisl.sourceforge.io. Same with stage1.

vonPalitroque commented on 2018-01-23 16:24 (UTC)

Greetings schnedan:

There is C++ support on the compiler (see line 65 of this PKGBUILD). However, libstdc++ is not built for two simple reason: it is too large for MSP430 targets and it needs proper libc support. This means that you can use all of the C++ language features supported by GCC, but you can not use C++ Standard Library features (e.g. templates and classes are good, things like std::vector<> are not). Remember that you are in a freestanding environment, so there is no operating system to help you with dynamic allocations so you will need to provide your own allocator, among other things.

You can use C++ (and link C++ code with msp430-elf-g++ instead of msp430-elf-gcc), but you can not link the C++ standard library as this is not built. The sheer size of the standard C++ library is one of the things that the Wiring environment attempt to address. Besides providing a hardware abstraction layer, Wiring also provides a makeshift C++ library tailored at embedded systems. This C++ library, however is not compatible in any way or form with the one dictated by ISO/IEC 14882, and does not provide its functionality.

You may try to enable building the C++ standard library by changing the PKGBUILD in line 76 to:

make all-gcc all-target-libgcc all-target-libstdc++-v3

Then 88 line to:

make DESTDIR="${pkgdir}" install-gcc install-target-libgcc install-target-libstdc++-v3

Please note that this is not guaranteed to work, and if it does, the C++ library will be too large to fit in an MSP430 anyway. You may also note that all other baremetal toolchains in Arch Linux enable C++ support in the compiler but do not enable the C++ standard library.

Cheers, Orlando.

schnedan commented on 2018-01-23 16:00 (UTC)

Hi,

  • multilib was not active (default on fresh install as it seems)
  • lib32-zlib installed manually (seems no dependency for msp430-elf-gcc or its dependencies)

so far now it works like I know it...

Final question: why there is only a libc and no libc++/libstdc++ ? -rw-r--r-- 2 root root 7844402 23. Jan 15:54 libc.a in /usr/msp430-elf/lib

This was why I tried an other fresh install in the VM as my C++ SW does not link after compile (error is about the missing lib), while the same Project as C-Code does... But I Want C++ working

vonPalitroque commented on 2018-01-19 16:23 (UTC)

Greetings,

My apologies, I got the file name wrong. The proper one is config.log

You will find a couple of them in your build directory:

$ find . -iname "config.log" ./libcpp/config.log ./intl/config.log ./lto-plugin/config.log ./libiberty/config.log ./libbacktrace/config.log ./libdecnumber/config.log ./build-x86_64-pc-linux-gnu/libcpp/config.log ./build-x86_64-pc-linux-gnu/libiberty/config.log ./build-x86_64-pc-linux-gnu/fixincludes/config.log ./gcc/config.log ./msp430-elf/libgcc/config.log ./msp430-elf/430/libgcc/config.log ./msp430-elf/large/libgcc/config.log ./isl/config.log ./config.log ./fixincludes/config.log

These are created as the configure script runs. I am mainly interested in the log for the configure script that fails. It should be somewhere in:

/tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/32/zlib

Now looking at the output of your configure script, it looks like gcc is trying to build its own internal zlib instead of using the system's. Also, it looks like you have the multilib repository enabled. I am not sure whether this is the case though. When I build this package, it does not attempt to build zlib alongside it. If this is the case, please make sure you have the lib32-zlib package installed and try to build again.

Cheers, Orlando.

PS. A few more notes, it looks like you are attempting to install msp430-elf-gcc and your AUR helper script goes on and fetch msp430-elf-gcc-stage1 as part of the process. Do you have msp430-elf-binutils installed already? If not, install that first. You should really build each portion of the toolchain separately, as your AUR helper script may get confused with what to pull in. The build order is in the msp430-elf-binutils package.

schnedan commented on 2018-01-19 12:32 (UTC)

hi,

thanks for the answer.

cannot find any file named configure.log... not in /tmp/yaourt-tmp-danny/, not anywhere else on the system...

started with yaourt -S msp430-elf-gcc

the process then fails when it tries to build msp430-elf-gcc-stage1

see here most of the console output (all cached lines...) https://ghostbin.com/paste/6jbew

vonPalitroque commented on 2018-01-18 16:44 (UTC)

Greetings,

@schnedan: I am unable to reproduce your issue in a fully up to date system. Can you please provide the configure.log file to examine the issue [1]? There seems to be something missing in your system to build this particular PKGBUILD.

Cheers, Orlando.

[1] Please use a paste service such as https://ghostbin.com instead of putting its contents here.

schnedan commented on 2018-01-18 16:06 (UTC)

current package seems to have a broken build I here use a clean arch (new install in a VM)

after executing yaourt -S msp430-elf-gcc the process started as normal... until

Running configure in multilib subdirs 32 pwd: /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/zlib Running configure in multilib subdir 32 pwd: /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... msp430-unknown-elf checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-pc-linux-gnu-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32 checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc -m32 accepts -g... yes checking for x86_64-pc-linux-gnu-gcc -m32 option to accept ISO C89... unsupported checking for style of include used by make... GNU checking dependency style of x86_64-pc-linux-gnu-gcc -m32... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by x86_64-pc-linux-gnu-gcc -m32... ld -m elf_x86_64 checking if the linker (ld -m elf_x86_64) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for ld -m elf_x86_64 option to reload object files... -r checking for x86_64-pc-linux-gnu-objdump... objdump checking how to recognize dependent libraries... pass_all checking for x86_64-pc-linux-gnu-ar... ar checking for x86_64-pc-linux-gnu-strip... strip checking for x86_64-pc-linux-gnu-ranlib... ranlib checking command to parse nm output from x86_64-pc-linux-gnu-gcc -m32 object... failed checking how to run the C preprocessor... /lib/cpp configure: error: in /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/32/zlib': configure: error: C preprocessor "/lib/cpp" fails sanity check Seeconfig.log' for more details. make: *** [Makefile:9074: configure-zlib] Fehler 1 ==> FEHLER: Ein Fehler geschah in build(). Breche ab... ==> FEHLER:Makepkg konnte msp430-elf-gcc-stage1 nicht erstellen. ==> Erstellen von msp430-elf-gcc-stage1 neu starten?[j/N] ==> ----------------------------------------------------- ==> n ==> Erstellen von msp430-elf-newlib neu starten?[j/N] ==> ------------------------------------------------- ==> n ==> WARNUNG:Vor dem Fehlschlag wurden Abhängigkeiten installiert

its reproduceable on another vm as well...

can you please verify and supply how to circumstance this behaviour?

vonPalitroque commented on 2017-01-16 15:41 (UTC)

Greetings promach, The msp430-elf-* packages utilize upstream sources to build the full toolchain. This is, in fact, what TI and their partners do for their msp430-gcc-opensource release. However, we utilize newer versions of the upstream software, and every once in a while we backport some patches (critical bugfixes and updating the microcontroller list across binutils and gcc) to ensure good functionality. The linker scripts and header files are exactly the same as TI's offering. As for the OpenMSP430 project, their documentation claims full compatibility with TI's core. As such, I do not see why these packages would not generate code that is compatible with that project. Please note that you may need to provide your own linker script and header files. Cheers, Orlando.

promach commented on 2017-01-15 23:50 (UTC)

Is this based on http://www.ti.com/tool/msp430-gcc-opensource ? Will this AUR package support https://github.com/olgirard/openmsp430 ?

Krakonos commented on 2016-10-22 18:58 (UTC)

It would seem that I'll need to use to old toolchain at least for some of my most constrained projects, until this is fully solved. I actually have one that barely fits, with just 40-50B left :-) However, it's good info and I'll definitely come back and do some digging. Thanks!

vonPalitroque commented on 2016-10-20 21:13 (UTC)

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

Krakonos commented on 2016-10-20 20:48 (UTC)

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>:

vonPalitroque commented on 2016-04-08 17:57 (UTC)

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

bulbus commented on 2016-04-08 08:20 (UTC)

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!

pftBest commented on 2015-11-21 21:06 (UTC)

This package works perfectly. Thank you!

vonPalitroque commented on 2015-10-22 13:33 (UTC)

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

kl1278 commented on 2015-10-22 03:53 (UTC)

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

vonPalitroque commented on 2015-10-01 13:23 (UTC)

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

vonPalitroque commented on 2015-09-29 21:08 (UTC)

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

kl1278 commented on 2015-09-29 11:23 (UTC)

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.

vonPalitroque commented on 2015-09-28 13:43 (UTC)

Greetings, Thank you for the report. I do not currently have a gdb package built for msp430-elf, although I can make one. Please note that newlib is built with no debugging symbols. I can build gdb for msp430-elf and do some testing on my own, but it would help if you provided a Makefile and a minimal example showing where you encounter the problem. Thank you. Cheers, Orlando.

kl1278 commented on 2015-09-28 03:35 (UTC)

Compiling using generated msp430-elf-gcc using -gstabs gave correct results for debugging. When using -gdwarf, gdb complains with this error: 'Single stepping until exit from function main, which has no line number information.' Examining the elf file with 'readelf --debug-dump=decodedline test.elf' showed no line numbers for my source files. Turning off garbage collection on sections produced line numbers with readelf, but still the same error in gdb about no line numbers. Anyway, -gstabs is working for now.

kl1278 commented on 2015-09-27 08:01 (UTC)

It installed without a glitch. Afterward it compiled my msp430 project without a problem. Debugging however was not possible as it gave me an error about missing line numbers. I tried it with gdb 7.10 and gdb 7.7. So I had to revert back to the the TI provided Compiler (MSP430-GCC 3_05_00_00). Same makefile, this time no errors. Any ideas?