On 19/02/15 11:21, Arvind Padmanabhan wrote:
> Thanks to both Eric and David for their inputs. Indeed, although "-Os
> -g" worked for me, it was difficult to set breakpoints at the right
> places. At times I had to resort single-stepping in assembly to get
> what I wanted.
> It is nice David pointed out that CCS default optimization is like
> 0.8 on mspgcc scale. I attempted "-O1 -g" and the code fits nicely in
> Flash. I also figured out that -g option affects only the ELF file
> size and has no effect on the program size downloaded to Flash.
> Option "-O3" explodes the code size. I assume it is sophisticated
> performance optimization probably involved lookup tables. Finally, I
> tried "-O1 -g3" (maximum debugging) and this is probably what I will
> use for debugging. See below for full comparison.

-O3 does things like extra inlining (inlining can save space or cost
space, depending on the size of the functions and the degree of
additional optimisations it allows - but -O3 inlines even when there is
significant cost in space), loop unrolling (which will be faster on an
msp430, but takes more space), and other such expensive optimisations.
It is seldom a useful choice.

Some compilers generate different code when debugging is enabled,
because they (and their matching debuggers) cannot track program state
for some types of optimisation.  gcc + gdb can do a pretty good job of
tracking the state even in heavily optimised code - so "-g" makes almost
no difference to the code generation.



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
Mspgcc-users mailing list

Reply via email to