in iar kickstart as i step through the program i noticed that my disassembly and
source are out of sync. I know the program downloaded and I have determined
that the program is executing the code correctly in the disassembly window but
the disassembly doesn't line up with the source shown in the source window.
In fact, the program counter is stopping at a commented line.
My target is an MSP430F2132.
Disassembly, source windows out of sync
Started by ●August 14, 2012
Reply by ●August 15, 20122012-08-15
Make sure to turn off optimizations in the compiler settings
--- In m..., "Wanda" wrote:
>
> in iar kickstart as i step through the program i noticed that my disassembly and source are out of sync. I know the program downloaded and I have determined that the program is executing the code correctly in the disassembly window but the disassembly doesn't line up with the source shown in the source window. In fact, the program counter is stopping at a commented line.
>
> My target is an MSP430F2132.
>
--- In m..., "Wanda" wrote:
>
> in iar kickstart as i step through the program i noticed that my disassembly and source are out of sync. I know the program downloaded and I have determined that the program is executing the code correctly in the disassembly window but the disassembly doesn't line up with the source shown in the source window. In fact, the program counter is stopping at a commented line.
>
> My target is an MSP430F2132.
>
Reply by ●August 15, 20122012-08-15
On 15/08/2012 09:27, distantship101 wrote:
>
> Make sure to turn off optimizations in the compiler settings
That's /terrible/ advice. It's like telling someone never to take their
car out of first gear to limit your chances of accidents.
The compiler will often re-arrange code, so that the order of the
generated assembly does not match the order of the source statements.
When single-stepping, you can expect to jump around a bit. And
sometimes the object code for a single C statement is spread around a
bit, so you jump back and forth.
The answer here is to get used to using your tools, and get a feel for
how they work. Sometimes you want to use the disassembly window to view
things or put breakpoints on exact points. Sometimes you want to add
extra code, such as writes to a volatile variable, to enforce order or
conditions to make debugging easier.
But what you /don't/ want to do is cripple your compiler - or even
worse, test and debug in non-optimised mode but build releases with
optimisation enabled (any time you see a project with "debug" and
"release" configurations, you should immediately delete the "release" one).
Anyway, in this particular case the debugger shows execution on a
comment line, which almost certainly indicates that the debug
information and the source code file are out of sync. Re-building the
project is probably the simplest first step.
>
> --- In m... ,
> "Wanda" wrote:
>>
>> in iar kickstart as i step through the program i noticed that my
> disassembly and source are out of sync. I know the program downloaded
> and I have determined that the program is executing the code
> correctly in the disassembly window but the disassembly doesn't line
> up with the source shown in the source window. In fact, the program
> counter is stopping at a commented line.
>>
>> My target is an MSP430F2132.
>>
>
> Make sure to turn off optimizations in the compiler settings
That's /terrible/ advice. It's like telling someone never to take their
car out of first gear to limit your chances of accidents.
The compiler will often re-arrange code, so that the order of the
generated assembly does not match the order of the source statements.
When single-stepping, you can expect to jump around a bit. And
sometimes the object code for a single C statement is spread around a
bit, so you jump back and forth.
The answer here is to get used to using your tools, and get a feel for
how they work. Sometimes you want to use the disassembly window to view
things or put breakpoints on exact points. Sometimes you want to add
extra code, such as writes to a volatile variable, to enforce order or
conditions to make debugging easier.
But what you /don't/ want to do is cripple your compiler - or even
worse, test and debug in non-optimised mode but build releases with
optimisation enabled (any time you see a project with "debug" and
"release" configurations, you should immediately delete the "release" one).
Anyway, in this particular case the debugger shows execution on a
comment line, which almost certainly indicates that the debug
information and the source code file are out of sync. Re-building the
project is probably the simplest first step.
>
> --- In m... ,
> "Wanda" wrote:
>>
>> in iar kickstart as i step through the program i noticed that my
> disassembly and source are out of sync. I know the program downloaded
> and I have determined that the program is executing the code
> correctly in the disassembly window but the disassembly doesn't line
> up with the source shown in the source window. In fact, the program
> counter is stopping at a commented line.
>>
>> My target is an MSP430F2132.
>>
Reply by ●August 15, 20122012-08-15
> But what you /don't/ want to do is cripple your
compiler - or even
> worse, test and debug in non-optimised mode but build releases with
> optimisation enabled (any time you see a project with "debug" and
> "release" configurations, you should immediately delete the "release" one).
I disagree. I always write and debug in "Debug" configuration until I get complete and functional code, then I switch to "Release" for testing.
Debugging to get the functionality right is much more time consuming with optimizations, not only because you are out of sync, but because you cannot trust the variables you see in the debugger since the compiler might get rid of some, or allocate the same storage to different variables. Furthermore, code compiles much faster without optimization, so it makes sense to turn them off until the code becomes somewhat stable.
> worse, test and debug in non-optimised mode but build releases with
> optimisation enabled (any time you see a project with "debug" and
> "release" configurations, you should immediately delete the "release" one).
I disagree. I always write and debug in "Debug" configuration until I get complete and functional code, then I switch to "Release" for testing.
Debugging to get the functionality right is much more time consuming with optimizations, not only because you are out of sync, but because you cannot trust the variables you see in the debugger since the compiler might get rid of some, or allocate the same storage to different variables. Furthermore, code compiles much faster without optimization, so it makes sense to turn them off until the code becomes somewhat stable.
Reply by ●August 15, 20122012-08-15
On 15/08/2012 10:21, distantship101 wrote:
>
>> But what you /don't/ want to do is cripple your compiler - or even
>> worse, test and debug in non-optimised mode but build releases
>> with optimisation enabled (any time you see a project with "debug"
>> and "release" configurations, you should immediately delete the
>> "release"
> one).
>
> I disagree. I always write and debug in "Debug" configuration until I
> get complete and functional code, then I switch to "Release" for
> testing.
>
> Debugging to get the functionality right is much more time consuming
> with optimizations, not only because you are out of sync, but
> because you cannot trust the variables you see in the debugger since
> the compiler might get rid of some, or allocate the same storage to
> different variables. Furthermore, code compiles much faster without
> optimization, so it makes sense to turn them off until the code
> becomes somewhat stable.
>
Well, obviously opinions and experiences vary - and /you/ do your
development work the way /you/ think is right. But I react against
"turn off optimisations" as advice to someone having problems - it is
almost invariably a bad idea.
The key point is that code acts differently with different optimisation
levels. There are obvious differences such as code speed and size, but
there are also a number of potential problems of the "it worked when
debugging without optimisation, but not when running with optimisation
enabled" type. These are almost invariably caused by incorrect coding -
missing "volatile" specifiers, mixups with aliasing, etc. If you are in
the habit of doing your debugging in separate configuration, you will
miss some of these - you will get code that worked fine when debugging,
and might well work under testing, but can fail in odd circumstances
(race conditions and volatiles or missing atomic accesses are typical
here). You get best results when you use the same configuration at all
times.
Occasionally, there are types of debugging with particular code in which
low optimisation is useful for single-stepping through algorithms. But
this is very much an exception.
>
>> But what you /don't/ want to do is cripple your compiler - or even
>> worse, test and debug in non-optimised mode but build releases
>> with optimisation enabled (any time you see a project with "debug"
>> and "release" configurations, you should immediately delete the
>> "release"
> one).
>
> I disagree. I always write and debug in "Debug" configuration until I
> get complete and functional code, then I switch to "Release" for
> testing.
>
> Debugging to get the functionality right is much more time consuming
> with optimizations, not only because you are out of sync, but
> because you cannot trust the variables you see in the debugger since
> the compiler might get rid of some, or allocate the same storage to
> different variables. Furthermore, code compiles much faster without
> optimization, so it makes sense to turn them off until the code
> becomes somewhat stable.
>
Well, obviously opinions and experiences vary - and /you/ do your
development work the way /you/ think is right. But I react against
"turn off optimisations" as advice to someone having problems - it is
almost invariably a bad idea.
The key point is that code acts differently with different optimisation
levels. There are obvious differences such as code speed and size, but
there are also a number of potential problems of the "it worked when
debugging without optimisation, but not when running with optimisation
enabled" type. These are almost invariably caused by incorrect coding -
missing "volatile" specifiers, mixups with aliasing, etc. If you are in
the habit of doing your debugging in separate configuration, you will
miss some of these - you will get code that worked fine when debugging,
and might well work under testing, but can fail in odd circumstances
(race conditions and volatiles or missing atomic accesses are typical
here). You get best results when you use the same configuration at all
times.
Occasionally, there are types of debugging with particular code in which
low optimisation is useful for single-stepping through algorithms. But
this is very much an exception.
