Stack checker broken on PowerPC/virtex BSP - 4.7.99.1 or later

[Joel Sherrill]

Robert S. Grimes wrote:
> Chris Johns wrote:
>   
>> Robert S. Grimes wrote:
>>     
>>> I see you have changed cpukit/score/include/rtems/score/object.h a tiny
>>> bit - is that the extent of this change?
>>>
>>>       
>> Yes that is the fix. It is small but it stops the score writing past
>> the end of the system object table. In other words it stops it
>> corrupting memory.
>>
>>     
> Yes, but that is not the memory being corrupted!  I have applied just
> the above mentioned patch to the 4.7.99.2 tarball, and the results are
> the same.
>
> I've narrowed it down to the invocation of this macro:
>
>     #define Stack_check_Dope_stack(_stack) \
>       memset((_stack)->area, BYTE_PATTERN, (_stack)->size)
>
> In the suspect code, this translates to this:
>      memset(0xe75c0, 0xa5, 0x2808);
>
> Thus, it is attempting to set the area from 0xE75C0 to 0xE9DC8
>
> This is the relevant output of the application build process - the .num
> map file:
>
>     000e0000 A stack.start
>     000e8000 A IntrStack_start
>     000e8000 A stack.end
>     000ec000 A intrStack
>     00100000 A _endloader
>     00800000 A _HeapSize
>
>
> A little fishy?  Yeah, but I don't know why...  Anyway, here is the
> exception output:
>
>     Exception handling initialization done
>     opb_intc_init: mask = 0x7
>     exception handler called for exception 7
>          Next PC or Address of fault = A5A5A5A4
>          Saved MSR = 0
>          R0 = A5A5A5A5
>          R1 = E7EB4
>          R2 = C56D8
>          R3 = 1
>          R4 = A5
>          R5 = 0
>          R6 = FEFFFFFF
>          R7 = D0000
>          R8 = D327C
>          R9 = E9DC8
>          R10 = 1
>          R11 = E9DC8
>          R12 = 0
>          R13 = FFFEA680
>          R14 = FFFFFFFF
>          R15 = FFFFFFFF
>          R16 = FFFFFFFF
>          R17 = FFFFFFFF
>          R18 = FFFFFFFF
>          R19 = FFFFFFFF
>          R20 = FFFFFFFF
>          R21 = FFFFFFFF
>          R22 = FFFE0000
>          R23 = FFFE0000
>          R24 = 0
>          R25 = D3154
>          R26 = 1
>          R27 = 0
>          R28 = D0000
>          R29 = D33FC
>          R30 = E0F38
>          R31 = A5A5A5A5
>          CR = 39000033
>          CTR = 0
>          XER = E000007F
>          LR = A5A5A5A5
>          MSR = 0
>          DAR = 0
>     Stack Trace:
>       IP: 0xA5A5A5A4, LR: 0xA5A5A5A5
>     --^ 0x00000000
>
>
> So it is clearly trying to execute code in the just-doped stack, though
> I don't know why...
>
> Anything else I should try?
>   
I really suspect that the RTEMS workspace (and possibly the
C Program Heap) is overlapping the initial stack and possibly
the interrupt stack

Break at RTEMS_Malloc_Initialize and look at the first
two arguments (start and length).

While there look at the first two entries in what
_Configuration_Table points to (workspace start and size).

Draw a memory map showing the range of your program's
text, data, bss, interrupt stack, starting stack, C Program
Heap, and RTEMS Workspace.

Give the symptoms and the addresses you posted above,
it is really looking like a memory map issue. 

--joel
> -Bob
>