bug in gcc-3.2.3/gcc/gthr_rtems.h

[EL KOLLI Yacine]

Joel Sherrill wrote:
> 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

Global constructors are not called

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

mine init looks like this:
0008059c <__init>:
    8059c:	94 21 ff f0 	stwu	r1,-16(r1)
    805a0:	7c 08 02 a6 	mflr	r0
    805a4:	90 01 00 14 	stw	r0,20(r1)
    805a8:	4b f8 9b a1 	bl	a148 <frame_dummy>
    805ac:	4b fd 1f e5 	bl	52590 <__do_global_ctors_aux>
    805b0:	80 01 00 14 	lwz	r0,20(r1)
    805b4:	7c 08 03 a6 	mtlr	r0
    805b8:	38 21 00 10 	addi	r1,r1,16
    805bc:	4e 80 00 20 	blr


And now I rember how I succeed in get it working. The problem was with 
the bsp_spec file, we need to add crtbegin and crtend to have the call 
to __do_global_ctors_aux.

I've filled a PR (378/bsps) for a first problem with bsp_specs not 
having a *endfile section.
But then I've done a second modification to have the global ctors 
called, and I forgot to file a PR..., my apologies :o((

My bsp_specs file looks like this:

%rename cpp old_cpp
%rename lib old_lib
%rename endfile old_endfile
%rename startfile old_startfile
%rename link old_link

*cpp:
%(old_cpp) %{qrtems: -D__embedded__} -Asystem(embedded)

*lib:
%{!qrtems: %(old_lib)} %{!nostdlib: %{qrtems: --start-group \
%{!qrtems_debug: -lrtemsbsp -lrtemscpu} %{qrtems_debug: -lrtemsbsp_g 
-lrtemscpu_g} \
-lc -lgcc --end-group \
%{!qnolinkcmds: -T linkcmds%s}}}

*startfile:
%{!qrtems: %(old_startfile)} %{!nostdlib: %{qrtems: \
%{!qrtems_debug: } \
%{qrtems_debug: }ecrti%O%s crtbegin%O%s}}

*endfile:
%{!qrtems: %(old_endfile)} %{qrtems: crtend%O%s ecrtn%O%s }

*link:
%{!qrtems: %(old_link)} %{qrtems: -dc -dp -u __vectors -u download_entry 
-N }



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


-- 
=====================================================
EL KOLLI Yacine         | yacine.elkolli at crf.canon.fr
Canon C.R.F.            | Phone: +33.(0)2.99.87.68.79
http://www.crf.canon.fr | FAX: +33.(0)2.99.84.11.30
====================================================