<offlist> or1k printf causes crash
Hesham Moustafa
heshamelmatary at gmail.com
Thu Aug 21 21:53:49 UTC 2014
On Thu, Aug 21, 2014 at 11:44 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> On 8/21/2014 4:04 PM, Christian Svensson wrote:
>> On Thu, Aug 21, 2014 at 9:56 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> The sp must be updated before the memory can be used. This is just
>>> a bug otherwise.
>> No, 128 byte redzone is an ABI thing both that OpenRISC and x86-64 have.
>> The bug in GCC was that redzone was not respected IIRC (if it's the
>> same bug that I have in mind).
> OK.
>
> Would it possibly need to be respected at the beginning of the interrupt?
> And at the transfer via _ISR_Dispatch?
I did so at the beginning of the interrupt, and before jumping to
_Thread_Dispatch from the _ISR_Handler; but I got the same behavior.
>>> R1 [SP]
>>> The stack pointer holds the limit of the current stack frame. The first 128 bytes below the stack pointer are reserved for leaf functions, and below that are undefined. Stack pointer must be word aligned at all times.
>>> Christian.. can you review that code?
>> Could you point me to the code? I don't know exactly which code and
>> version is being used.
> http://git.rtems.org/rtems/tree/cpukit/score/cpu/or1k/rtems/score/cpu.h
>
> around line 548. That is implemented using _OR1K_mtspr which is
> around line 336 of
>
> http://git.rtems.org/rtems/tree/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h
>
> These asm constraints are always so hard to get right.
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
More information about the devel
mailing list