Stack full or something else?

[Joel Sherrill]

On 11/12/2010 01:05 PM, João Rasta wrote:
> Hi Daron,
>
> It is running on a LEON-3. The application exits raising the following 
> exception:
>
> IU in error mode (tt = 0x07)
>
> which is a memory access to an unaligned address. The last instruction 
> is this:
>
> 4003bd74  d0006034   ld  [%g1 + 0x34], %o0
>
What is the value of g1?  Is it unaligned?
> I don't understand why i have this error. The code where this error is 
> being reported is compiled independently and then put in a library, 
> but it uses the same cross-compiler as the main source code. I don't 
> think i'm doing something wrong while compiling the library files, i 
> use the same compilation flags..
>
> What can i be missing to have unaligned memory accesses?
>
>
> Best,
> JM
>
>
>
> On Fri, Nov 12, 2010 at 6:43 PM, Daron Chabot <daron.chabot at gmail.com 
> <mailto:daron.chabot at gmail.com>> wrote:
>
>
>     On Fri, Nov 12, 2010 at 11:50 AM, João Rasta
>     <freakforever at gmail.com <mailto:freakforever at gmail.com>> wrote:
>
>         Hi,
>
>         I have an RTEMS POSIX API application which comes to a point
>         that if a small function (with some doubles passed as
>         arguments) is called, the application exits with an error. At
>         first i thought of increasing the stack space. I did this with
>         CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE but the problem remains
>         even if i remove all the contents of the function.
>
>         1) Am i setting up the stack size correctly? I think i am, but
>         i ask just in case..
>
>         2) Is there any other explanation to why a function call
>         crashes the application besides having a full stack? Again, i
>         erased the function contents..
>
>
>     What architecture is this running on ?
>
>     What is the application exit error (message and/or return code)?
>
>     It looks like all POSIX threads are created as floating-point
>     tasks (FP state saved across context switches), so there
>     "shouldn't" be a problem on that aspect...
>
>
>
>         Best,
>         JM
>
>
>
>         _______________________________________________
>         rtems-users mailing list
>         rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>         http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>


-- 
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