You are so right! Of course the demo code had reduced this just to a mainline, which is where this problem is exhibited. I have just thrown a dummy call frame in and the problem has disappeared. I can definitely live with that and/or optimisation until its finally fixed.
And I though optimisation was a prime way of confusing debuggers, not the other way round... Thanks to you both for the rapid clarification. Andrew -----Original Message----- From: Peter Bigot [mailto:big...@acm.org] Sent: Saturday, 10 December 2011 1:04 a.m. To: and...@aratika.co.nz Cc: mspgcc-users@lists.sourceforge.net Subject: Re: [Mspgcc-users] Invalid addresses for stack variables in GDB? https://sourceforge.net/tracker/?func=detail&aid=3420924&group_id=42303&; atid=432701 may be relevant if your local variables are in main(). Enabling optimization may help. Peter On Thu, Dec 8, 2011 at 10:06 PM, Andrew McLaren <and...@aratika.co.nz> wrote: > 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 > ------------------------------------------------------------------------------ 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
