Package Details: msp430-elf-gcc 11.2.0-1

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
Last Updated: 2021-09-13 15:46

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

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

vonPalitroque commented on 2015-10-01 13:23

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

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

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

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.