bug in gcc-3.2.3/gcc/gthr_rtems.h

Joel Sherrill joel.sherrill at OARcorp.com
Wed Apr 21 16:04:32 UTC 2004


EL KOLLI Yacine wrote:

> Joel Sherrill wrote:
> 
>> EL KOLLI Yacine wrote:
>>
>>> Comment interleaved, hope it helps..
>>
>>
>>
>> I think we are getting there.  We might be fixing two things. :(
> 
> 
> well that can be a good news ;o)
> 
>>>> EL KOLLI Yacine wrote:
>>>>
>>
>>>> I rebuilt completely a toolset and RTEMS for psim so that
>>>> shouldn't be a problem.
>>>>
>>>> I am still not getting a break at rtems_gxx_mutex_init
>>>> and the test is obviously failing.
>>>
>>>
>>>
>>>
>>> Are you sure that your c++ test is using STL ?
>>
>>
>>
>> Hmmm.. that may be a hint.  I added your list
>> code before the cout.  Now rtems_gxx_mutex_init
>> is being called but the test fails on the cout.
>>
>> Can you run the cdtest when
>> RTEMS_TEST_IO_STREAM is defined in main.cc?
> 
> 
> yes and It works.
> 
> 
> I've modified the _Thread_Handler function to make it calling _eabi() 
> instead of _init(). I've done this a while a go, when I was trying to 
> get the IO streams working. But I'don't remember if that solves my 
> problem, nor why I have not submitted the modification :o(.
> 
> When you run cdtest global constructors should print a message on sreen 
> before the main message. Do you have the print out from the global 
> constructors ?
> 

*** CONSTRUCTOR/DESTRUCTOR TEST ***
LOCAL: Hey I'm in base class constructor number 1 for 0x7e94b8.
LOCAL: Hey I'm in base class constructor number 2 for 0x7e94c8.
LOCAL: Hey I'm in base class constructor number 3 for 0x7e94d8.
LOCAL: Hey I'm in base class constructor number 4 for 0x7e94e8.
LOCAL: Hey I'm in derived class constructor number 5 for 0x7e94e8.
core_find_mapping() - access to unmaped address, attach a default map to 
handle this - addr=0xfffffff4 nr_bytes=0x4 processor=0x407c9008 cia=0x492d4

I forced a call to __eabi() which ended up calling _init, doing
a few instructions and returning.  _init() is called from
_Thread_Handler so that seems OK.  The _init body is only this:

0x55a10 <_init>:        stwu    r1,-16(r1)
0x55a14 <_init+4>:      mflr    r0
0x55a18 <_init+8>:      stw     r0,20(r1)
0x55a1c <_init+12>:     lwz     r0,20(r1)
0x55a20 <_init+16>:     mtlr    r0
0x55a24 <_init+20>:     addi    r1,r1,16
0x55a28 <_init+24>:     blr

Does this more or less match yours?

The linker script has to be just right to make the constructors
happen.  I copied the ctor/dtor pattern from the gen405 but without
luck.  Could you see what might be broken in the psim linkcmds?

--joel




More information about the users mailing list