Coldfire C++ compiler problem

[awebster]

Using codewarrior 6.3 professional edition on a PCF52235, I've noticed (in several cases) that the compiler generates asm for code similar to the example in the following manor:

MyClass::Alloc(int size)

{
  if (size)

  {

     m_buffer = calloc1(size);

XXXXXXX1: 202E0014        move.l   20(a6),d0

XXXXXXX2: 2E80            move.l   d0,(a7)

XXXXXXX3: 4EB90000DC1C    jsr      calloc1 (0xdc1c)

XXXXXXX4: 2D40FFFC        move.l   d0,-4(a6)

XXXXXXX5: 202EFFFC        move.l   -4(a6),d0

XXXXXXX6: 2D40FFF0        move.l   d0,-16(a6)

XXXXXXX7: 206E0008        movea.l  8(a6),a0

XXXXXXX8: 202EFFF0        move.l   -16(a6),d0

XXXXXXX9: 21400004        move.l   d0,4(a0)

  }

}

I'm not sure why I see the return from calloc1 being put into -4(a6) and -16(a6), and most of the time I wouldn't worry about it, but in some cases when this happens, there were less than 16 bytes alloced on the frame at the beginning of the method (link  a6,#0; lea  -8(a7),a7; ...).  So, if an interrupt fires between 'move.l  d0,-16(a6)' and 'move.l  -16(a6),d0', -16(a6) gets corrupted and m_buffer ends up with an illegal address.

Additionally, I am running into another problem with these instructions.  Even with interrupts disabled and more than 16 bytes alloced for the frame, -16(a6) is still corrupted in some cases (but repeatable) when the processor is allowed to execute the instuctions without breaks in between.  For example, under the following scenario, -16(a6) is corrupted:

 1. Set break points at lines 4 and 9 from above

 2. Once the break point at 4 is hit, let the processor run

 3. When the break point at 9 is hit, -4(a6) has the correct value for d0 in it, but -16(a6) does not (always ends up with the same incorrect value)

But if I step through each line between 4 and 9, when 9 is reached, both -4(a6) and -16(a6) have the correct value in them.

Any Ideas?

[CompilerGuru]

strange,
can you provide a complete compilable sample?
With the code you did show, this did not happen for me.
(means, I did not get those accesses outside of the allocated area.)
Best would be a simple project (mcp) with a source file causing this.

The behavior you see with the breakpoint at line 4&9 is probably caused because the debugger sets a software breakpoint at line 9 and and then lets the core run. When the software breakpoints triggers, the core does issue an exception, and this does write to the stack of course. You could check if this behavior does not happen with a Hardware breakpoint, but anyway, the code must never access not allocated stack space, so this only to understand the behavior.

Daniel

[awebster]

Unfortunately I don't remember the scenario that caused the compiler to use memory outside of the frame.  However, the project I attached does exhibit the extra copy of the result to a second place in the frame.  In the ctor, the result of calloc1 is copied to -4(a6) and -16(a6), and in the method, the result is copied to -4(a6) and -8(a6).  The scenario I saw before had the same code as the method (the frame was created with 'lea -12(a7)'), but copied the result into -4(a6) and -16(a6) (as in the ctor).

The problem I had today was in the ctor.  The ctor could run 100's of times with no problem, but under certian circumstances, there would always be an exception.  The exception occurs because the frame (-16(a6)) was corrupted and "buffer" ended up with an invalid pointer.  When I step through the assembly, there is no corruption, but when I just let it run, I always get an exception (in this case there are no interrupts enabled at the time, except the unmaskable ones, and -16(a6) is within the frame).  I've had this problem before with this processor in different sections of code, but it would go away on it's own as I did more development in other places in the code.  In this case, I solved the problem by inlining the same generated assembly, but minus the extra copy and restore at -16(a6).

[CompilerGuru]

as you already said, this code does not show the same problem as before.
The compiler generated code does not access not allocated memory. So as you still have this strange behavior, I wonder where it comes from. When looking at the code, it does not seem to be the compiler. As it only happens when you run the code, I doubt its the debugger (the debugger only does something when it does not run...). So what's left? Could this be some HW issue? Or not enough stack? Or some other code interfering?
strange.

Daniel