PC386 Question Info in Exception Message

[Joel Sherrill]

Nickolay Kolchin wrote:
> Hi,
>
> Confirmed. GCC 4.3-20080208 never correctly finish RTEMS executable.
>
> RTEMS Current CVS, PC386, Newlib 1.16, Qemu 0.9.1.
>
>   
Thanks.
> The source of interrupt is __do_global_dtors_aux, declared in gcc/crtstuff.c
>
> 0x1000a6 <__do_global_dtors_aux+42>:    xchg   %ax,%ax
> 0x1000a8 <__do_global_dtors_aux+44>:    lea    0x1(%edx),%eax
> 0x1000ab <__do_global_dtors_aux+47>:    mov    %eax,0x120ef4
> 0x1000b0 <__do_global_dtors_aux+52>:    call   *0x11b034(,%eax,4)
> 0x1000b7 <__do_global_dtors_aux+59>:    mov    0x120ef4,%edx
> 0x1000bd <__do_global_dtors_aux+65>:    cmp    %ebx,%edx
> 0x1000bf <__do_global_dtors_aux+67>:
>
> after 0x1000b0 we get our interrupt.
>   
I was seeing this type of thing on SPARC and actually
commented out the call to _init in _Thread_Handler
to get around it.  I meant to return to this but forgot.
Something has changed in the way the .ctor/.init section
is constructed.  I

Can you do an objdump on an executable that works
and one that doesn't and see what's different in the
section?

Does anyone see anything that's changed after 4.2.3
in ctor/init construction or handling?  __do_global_ctors_aux()
in crtstuff.c looks the same to me.

I notice that the default linkcmds for i386 binutils has
the init section like this:

  .init           :
  {
    KEEP (*(.init))
  } =0x90909090

And the BSP has

    .init : { *(.init) } = 0x9090

But this also happens on sparc/sis which means it isn't
BSP specific.

--joel
> On 2/11/08, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>   
>> Hi,
>>
>>  I don't have time to look into this and was hoping
>>  someone out there could explain it or fix it. :D
>>
>>  I am trying to do as much testing of gcc's SVN trunk
>>  before 4.3.0 is out.  I have reasonably good results
>>  on SPARC/sis and PowerPC/psim but ~300 of the ~2300
>>  tests for i386/pc386 on qemu fail with something like
>>  this:
>>
>>  =================================
>>
>>  ---- CB20001 Check that exceptions can be handled in accept bodies.
>>  ----------------------------------------------------------
>>   Exception 6 caught at PC 4C by thread 184614915
>>   ----------------------------------------------------------
>>   Processor execution context at time of the fault was  :
>>   ----------------------------------------------------------
>>   EAX = 172975    EBX = 1622D0    ECX = 1729E5    EDX = 1729A8
>>   ESI = 4    EDI = 4    EBP = 2221E0    ESP = 172770
>>   ----------------------------------------------------------
>>   Error code pushed by processor itself (if not 0) = 0
>>   ----------------------------------------------------------
>>   ************ FAULTY THREAD WILL BE DELETED **************
>>  =================================
>>
>>  Since PC=4C is down in the vector table, I am rather suspicious
>>  it is not in the RTEMS application.  Exception 6 is an illegal
>>  instruction. So it could be something qemu doesn't like,
>>  a blown stack, etc.  But this message doesn't point to
>>  something that I can find via objdump.
>>
>>  Any thoughts?  Fixes?
>>
>>
>>  --
>>  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
>>
>>
>>  _______________________________________________
>>  rtems-users mailing list
>>  rtems-users at rtems.com
>>  http://rtems.rtems.org/mailman/listinfo/rtems-users
>>
>>     
>
> ---
> Nickolay
>   


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