Package Details: msp430-elf-gcc 7.2.0-1

Git Clone URL: https://aur.archlinux.org/msp430-elf-gcc.git (read-only)
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: 11
Popularity: 0.250586
First Submitted: 2015-09-19 18:38
Last Updated: 2017-09-25 14:54

Latest Comments

vonPalitroque commented on 2017-01-16 15:41

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

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

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

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

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

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

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

This package works perfectly.
Thank you!

vonPalitroque commented on 2015-10-22 13:33

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

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

All comments