I've just upgraded to the uniarch mspgcc (20110716-p20111105 running on
Windows), and am having some strange issues in GDB, which appear to be
GDB having wrong addresses for variables located on the stack. I threw
together a very simple bit of code, which simply updated a variable with
a value, and had a peek at both the debugger, and the assember code.
This is what I am seeing;
C code
# uint16_t test1;
# ...
# test1 =1;
When this line is executed, GDB shows test1 as unchanged, but an
adjacent variable is updated to 1.
The disassembly at this point;
# 00001188: mov #1, -6(r4) ;r3 As==01, 0xfffa(r4)
r4 has a value of 0xA02 at this point, which would give the target
location of of test1 as 0x9FC. However, the debugger gives me location
0x9FA for test1. If I change the test1 declaration to static, everything
maps fine.
Its a bit hazy, as I am not quite sure what to trust at present. I am
running GDB via Eclipse, and upgraded to Eclipse Indigo at the same
time, so mspgcc wasn't the only thing that moved. I've has a troll
through the mspgcc databases, and there was a similar problem reported
under ID 3417263, but this should have been resolved in the 20110716
release.
Are there any known issues around the debug symbols being produced by
mspgcc? I'm using the -ggdb compile option to msp430-gcc, but have tried
other debug options with no change.
Regards
Andrew
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
