Quantcast

MSP430 RedHat Toolchain: minor issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MSP430 RedHat Toolchain: minor issues

Chris Liechti
I'm updating a larger project to compile with the RH port of gcc for
MSP430 as well as previous mspgcc versions. I've noticed a few problems.

versions used from http://www.ti.com/tool/msp430-gcc-opensource:
- GCC_RH_20131206.zip
- msp430-130423-272-source.tar.bz2 (resp. the provided windows command
line binaries)

== 1)

iomacros.h includes the following 4 lines in the section that is parsed
by "as" and "cc"

#define const_sfrb(x,x_) const sfrb_(x,x_)
#define const_sfrw(x,x_) const sfrw_(x,x_)
#define const_sfra(x,x_) const sfra_(x,x_)
#define const_sfrl(x,x_) const sfrl_(x,x_)

it is an error for "as" when it sees the "const". solution: move these
line in between the #ifdef'd part where only the c compiler sees it and
add the following to the section for the assembler.

#define const_sfrb(x,x_) x=x_
#define const_sfrw(x,x_) x=x_
#define const_sfra(x,x_) x=x_
#define const_sfrl(x,x_) x=x_

== 2)

.noinit segment is not correctly flagged, it is needlessly downloaded to
the target and occupies flash for a series of zeros. objdump shows

...
  8 .rodata       000009dc  00002100  00002100  00000194  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .text         0000acd2  00002adc  00002adc  00000b70  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .data         0000035c  00001100  0000d7ae  0000b844  2**1
                  CONTENTS, ALLOC, LOAD, DATA
 11 .bss          00000808  0000145c  0000db0a  0000bba0  2**1
                  ALLOC
 12 .noinit       000002f1  00001c64  0000db0a  0000bba0  2**1
                  CONTENTS, ALLOC, LOAD, DATA
...

and objcopy seems to include the zeros from .noinit in the .a43 (intel hex).

== 3)

it looks like COMMON is included in the ".noinit" section, i thought it
belongs to the ".bss" section.

there are multiple "end" labels defined, one in ".bss" and one in ".noinit"

and unfortunately "_end" is placed in .bss instead of the very end of
RAM (behind .noinit) as it was in mspgcc.

(seen in the ld files for msp430f2410 and others)

== 4)

and probably not MSP430 specific, with -Os "static inline functions()"
are not inlined, i also tried adding __attribute__((always_inline)) but
it did not seem to have an effect in a quick test.

we are using such one-line functions for pin access. when not inlined
the call will probably increase the code size considerably with register
moving to prepare a call to one assembler line that does not even touch
a register...

we used to use -O2 only but the code is a little bit larger with GCC 4.x
so we added -Os ...

== 5)

it was probably a design decision to change the ABI and start with R12
instead of R15 for parameters. this leads to some work with assembler
modules interacting with c modules.

it would be nice if there where some defines available to detect the
ABI. i've passed a -D from the command line depending on which compiler
is used (old mspggc/ti gcc).


i'm also not getting any source, just assembler, with "objdump -dSt" of
the .elf file, which previously worked.

====

positively, after working around these issues (we use custom linker
scripts anyway as we reserve space for a bootlaoder, MSP430F2xx) it
compiles and runs :-)


thanks,
chris


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MSP430 RedHat Toolchain: minor issues

DJ Delorie

Some quick answers where available...

> and probably not MSP430 specific, with -Os "static inline
> functions()" are not inlined, i also tried adding
> __attribute__((always_inline)) but it did not seem to have an effect
> in a quick test.

Please try "extern inline functions()" instead.  There was a change in
the ISO standard that's been tripping up lots of software like this.

> it was probably a design decision to change the ABI and start with
> R12 instead of R15 for parameters. this leads to some work with
> assembler modules interacting with c modules.

The ABI is intended to be compatible with TI's own compiler.

> positively, after working around these issues (we use custom linker
> scripts anyway as we reserve space for a bootlaoder, MSP430F2xx) it
> compiles and runs :-)

Woot!

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MSP430 RedHat Toolchain: minor issues

David Brown-4
On 14/01/14 03:00, DJ Delorie wrote:

>
> Some quick answers where available...
>
>> and probably not MSP430 specific, with -Os "static inline
>> functions()" are not inlined, i also tried adding
>> __attribute__((always_inline)) but it did not seem to have an effect
>> in a quick test.
>
> Please try "extern inline functions()" instead.  There was a change in
> the ISO standard that's been tripping up lots of software like this.
>

"extern inline" has different semantics than "static inline".  It will
not often make a difference, but it /could/ happen (for example, I
believe an "extern inline" function may not refer to "static const"
data, whereas a "static inline" function can do so).  It is also
important that "static inline" functions get properly inlined, because
they are heavily used in real-world code and work as expected on other
compilers.

Also, if I understand the complicated rules correctly, there is a
difference in C++ - with "extern inline" you must be sure that all
definitions in all translation units are identical, while with "static
inline" they can be different.


I believe, but I'm not sure, that if a "static inline" function with the
"always_inline" attribute is /not/ inlined, then this is a bug in the
compiler - according to the manual, such functions will always be
inlined even with no optimisation specified (unless you have the
-fno-inline flag active).


Certainly it is worth compiling with the "-Winline" flag to see /why/
these "static inline" functions are not being inlined.

It is also usually worth enabling "-finline-small-functions" - if the
heuristics used are accurate, this should be enabled for -Os as it will
lead to smaller code (according to the manual).


>> it was probably a design decision to change the ABI and start with
>> R12 instead of R15 for parameters. this leads to some work with
>> assembler modules interacting with c modules.
>
> The ABI is intended to be compatible with TI's own compiler.
>
>> positively, after working around these issues (we use custom linker
>> scripts anyway as we reserve space for a bootlaoder, MSP430F2xx) it
>> compiles and runs :-)
>
> Woot!
>

It is great to hear of this success.  Of course, it is not unexpected,
given the company and people doing the gcc port (and Chris is not
exactly a newbie here!).  I look forward to using the new toolchain
myself in the future.

mvh.,

David



------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Loading...