code size

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

code size

Kees Schoenmakers
I tried the newer msp-GCC (TI/RedHat) distribution on my project(s).

It still builds with _far_ more code then my present msp430-gcc
(4.7.0). This compiler
has also some minor habits but produces compact code.

So for the moment I will not switch to the newer version, my project
would not fit in the flash.

best regards,

Kees

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Eric Price
On Fri, 12 Dec 2014 11:43:59 +0100
Kees Schoenmakers <[hidden email]> wrote:

> I tried the newer msp-GCC (TI/RedHat) distribution on my project(s).
>
> It still builds with _far_ more code then my present msp430-gcc
> (4.7.0). This compiler
> has also some minor habits but produces compact code.
>
> So for the moment I will not switch to the newer version, my project
> would not fit in the flash.
>

I have had similar issues in the beginning.
It seems the new compiler does link in every function present in the
code and libc - even if its not used, bloating up the code
significantly.

This however can be worked around with some additional compiler flags,
to turn on link time optimization and garbage collection, which the new
compiler does support, but is not turned on by default.

add to compiler flags:

> -fdata-sections
> -ffunction-sections
> -fno-asynchronous-unwind-tables
> -flto

and to linker flags
> --gc-sections
> --print-gc-sections

this will cause the compiler to mark each function and data section in
the resulting object file, which allows the linker to garbage collect
unused functions (stripped functions are printed thanks to
print-fc-sections)

there are still some bugs, for example if linking a lot of code
together the compiler suddenly issues a lot of

> warning: visibility attribute not supported in this configuration; ignored [-Wattributes]

warnings for no apparent reason in random places in the code.

This was also the case with the previous version of the TI/Redhat
compiler released in the middle of the year.

As far as I could see so far these linker warnings can be safely
ignored, the resulting code still works and is still significantly
smaller than without -flto and --gc-sections

hope that helps.

cheers

Eric

--
Eric Price
TTI GmbH - TGU Smartmote
Pfaffenwaldring 4
D-70569 Stuttgart

Tel.: +49 0711 - 6856 5369
Fax.: +49 0711 - 6856 6818
E-mail: [hidden email]
Homepage: http://www.smartmote.de

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Peter Bigot-4
In reply to this post by Kees Schoenmakers
On Fri, Dec 12, 2014 at 4:43 AM, Kees Schoenmakers <[hidden email]>
wrote:

> I tried the newer msp-GCC (TI/RedHat) distribution on my project(s).
>
> It still builds with _far_ more code then my present msp430-gcc
> (4.7.0). This compiler
> has also some minor habits but produces compact code.
>
> So for the moment I will not switch to the newer version, my project
> would not fit in the flash.
>

Yes, code size is not as one might wish.  See
http://e2e.ti.com/support/development_tools/compiler/f/343/p/384317/1356674#1356674
for some information, as well as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027

Those issues, unfortunately, are not solved by linker optimizations.  (IRT
Eric: I was unaware of the visibility attribute, so haven't run into that,
though I can see it will be useful in the future.)

My core blockers for msp430-elf are an official patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 and a new release of the
support headers/linker scripts that reverts the broken initialization
infrastructure (which I assume TI is working on).

But since mspgcc doesn't build on Ubuntu 14.04 the code size issue does
become more important.  The E2E response hints that we're running into an
organizational conflict of interest at TI.

Peter

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Matthias Ringwald-3
Hi


> On 12.12.2014, at 12:57, Peter Bigot <[hidden email]> wrote:
> .. But since mspgcc doesn't build on Ubuntu 14.04 the code size issue does
> become more important.  ...


not really related to the code size problem but I'd like to recommend the use of Docker for the case where the default compiler causes problems. After failing to properly compile our desktop apps for 32-bit on a 64-bit built machine, we switched to compiling it from a 32-bit linux Docker container. As it is a container and we only use for this particular built task, we're free to try to use newer linux distributions easily.

(note: this is not intended to stop Peter from helping out in getting the msp430-elf usable by the masses)

Best
 Matthias


 


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Richard Weickelt
In reply to this post by Peter Bigot-4

> The E2E response hints that we're running into an
> organizational conflict of interest at TI.

the main thing I miss from TI's side is communication. All we've heard so
far is, "We have this new toolchain thingy here. Like it or lump it." This
is not open source development. It would be good, if TI could be more open
and explain, what they're going to do, why and how. So that if a RH engineer
shows up here, willing to help, he wouldn't receive all the blames.

I remember an Atmel engineer doing this a couple of years ago with avr-gcc
and I always found that very informative.

Might be, that TI's ignorance of the previous community efforts happens for
a reason, e.g. not getting in touch with poisonous code (license). But
that's hard to believe.





------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

nick clifton
In reply to this post by Eric Price
Hi Eric,

> there are still some bugs, for example if linking a lot of code
> together the compiler suddenly issues a lot of
>
>> warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
>
> warnings for no apparent reason in random places in the code.

That sounds interesting.  Could you send me a small testcase to
reproduce the problem ?  Or better yet file a bug report (with the FSF
or TI) including the testcase, and then I can look into it.

Cheers
   Nick



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Eric Price
On Tue, 16 Dec 2014 10:47:30 +0000
Nicholas Clifton <[hidden email]> wrote:

> Hi Eric,
>
> > there are still some bugs, for example if linking a lot of code
> > together the compiler suddenly issues a lot of
> >
> >> warning: visibility attribute not supported in this configuration;
> >> ignored [-Wattributes]
> >
> > warnings for no apparent reason in random places in the code.
>
> That sounds interesting.  Could you send me a small testcase to
> reproduce the problem ?  Or better yet file a bug report (with the
> FSF or TI) including the testcase, and then I can look into it.
>
> Cheers
>    Nick
>
>

The only test case I have so far that reproduces it contains a lot of
proprietary code that I unfortunately cannot share here. I yet have to
create an artificial simplified test case.

The problem is, I was only able to reproduce it when linking together
a relatively large code base with lots of functions, and only when many
of these functions were actually being used.

Any attempt to simplify the test case by reducing code, or even
just calls to that code - which was the first thing I tried, made the
error "magically" disappear. That happened regardless of which function
calls were eliminated.

That way I couldn't pinpoint any specific code as the culprit, it
rather looks like the error only appears when a certain code complexity
is surpassed. I'd guess maybe because it overwhelms the linker garbage
collector or makes it switch optimization schemes internally or
something. It's hard to tell without more detailed knowledge of whats
going on linker-internally.

Assume the following program was triggering the bug (with function1
and 2 implemented in previously compiled and now to be linked in object
files)

void function1(void);
void function2(void);

int main() {
        function1();
        function2();
        exit 0;
}

then these two simplified programs both did not trigger it:

int main() {
        function1();
        /* function2(); */
        exit 0;
}

int main() {
        /* function1(); */
        function2();
        exit 0;
}




--
Eric Price
TTI GmbH - TGU Smartmote
Pfaffenwaldring 4
D-70569 Stuttgart

Tel.: +49 0711 - 6856 5369
Fax.: +49 0711 - 6856 6818
E-mail: [hidden email]
Homepage: http://www.smartmote.de

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

nick clifton
Hi Eric,

>>>> warning: visibility attribute not supported in this configuration;
>>>> ignored [-Wattributes]

> The problem is, I was only able to reproduce it when linking together
> a relatively large code base with lots of functions, and only when many
> of these functions were actually being used.

Hang on - you say that you are getting this message during *linking* ?
The error message comes from the compiler, not the linker, so why is it
turning up in the linker's output ?  Do you have LTO enabled ?  (If you
do, does disabling LTO make the problem go away ?)

Also, if you add -Wno-attributes to the command line, does the problem
go away ?  (I assume that you are not otherwise using unsupported
attributes, so disabling the warning would not be a big issue).  Just a
thought - I know that this is not a real solution to the problem.


> Any attempt to simplify the test case by reducing code, or even
> just calls to that code - which was the first thing I tried, made the
> error "magically" disappear. That happened regardless of which function
> calls were eliminated.

I hate these kinds of bugs. :-{

Are there any clues as to where the compiler/linker thinks that the
visibility attribute is being used ?

Cheers
   Nick



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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
|

Re: code size

Eric Price
On Wed, 17 Dec 2014 17:04:08 +0000
Nicholas Clifton <[hidden email]> wrote:

> Hang on - you say that you are getting this message during
> *linking* ? The error message comes from the compiler, not the
> linker, so why is it turning up in the linker's output ?  Do you have
> LTO enabled ?  (If you do, does disabling LTO make the problem go
> away ?)
>

Yes, The error only happens with -flto enabled, disabling -flto makes
the error disappear.

(but "NOT using -flto" also increases the resulting code size by a quite
significant factor, so that's unfortunately not a solution)

No other optimization flags are needed to reproduce the error. No
linker flags need to be enabled explicitly either.

I could reproduce the issue by simply compiling all files with:

> msp430-elf-gcc -Wall -g -c -O0 -flto file.c -o file.o
(this does not cause any errors)

and then linking them with

> msp430-elf-gcc *.o -o file.elf
(this does cause the errors)

Once the errors start appearing, there are always LOTS of them,
but they always have one of the following forms:

variant 1:

> myfile.c: In function ‘xy’:
> myfile.c:88:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
>  }
>  ^

where the error always point to the line with the closing bracket at the
end of a function.
This is repeated for many functions throughout the codebase (hundreds)
but interestingly not all functions used. I could not find out why this
would appear for one function and not for another.

for example I haven't seen this appear at the end of main() {}

variant 2:

> At top level:
> lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
> lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
> lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
> lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
> lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
... (repeated a hundred times)


cheers

Eric

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users