RTEMS C++ global constructor for Sparc

Daniel Hellstrom daniel at gaisler.com
Tue Apr 1 20:09:32 UTC 2014


Hi,

The SPARC v7/v8 traps ends at 255, I dont have RTEMS code in front of me, perhaps there is a mask of 0x100 added to the trap number to indicate something.

Daniel

On 1 April 2014 17:44:38 CEST, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>OK.. replying to self..
>
>I made some changes locally and now have the examples-v2 sample
>cxx_throw nearly running.  I am down to the spurious exception handler
>getting invoked on sis for exception 263 which I don't know what that
>is.  [1]
>
>Does this run in gdb or exception mean anything to anyone?
>
>(gdb) r
>Starting program:
>/home/joel/rtems-4.11-work/examples-v2/cxx/cxx_throw/o-optimize/cxx_throw.exe
>
>Hey I'm in base class constructor number 1 for 0x2068384.
>Hey I'm in base class constructor number 2 for 0x206837c.
>Hey I'm in derived class constructor number 3 for 0x206837c.
>
>
>*** CONSTRUCTOR/DESTRUCTOR TEST ***
>Hey I'm in base class constructor number 4 for 0x20730f0.
>Hey I'm in base class constructor number 5 for 0x20730f8.
>Hey I'm in base class constructor number 6 for 0x2073100.
>Hey I'm in base class constructor number 7 for 0x2073108.
>Hey I'm in derived class constructor number 8 for 0x2073108.
>Testing a C++ I/O stream
>before try block
>
>Breakpoint 1, _Terminate (
>    the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
>is_internal=is_internal at entry=false,
>the_error=the_error at entry=34011320)
>    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
>36    {
>(gdb) bt
>#0  _Terminate
>(the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
>is_internal=is_internal at entry=false,
>the_error=the_error at entry=34011320)
>    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
>#1  0x0203c454 in rtems_fatal (
>    source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
>    error=error at entry=34011320)
>    at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
>#2  0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131
>#3  0x0205fda4 in dont_fix_pil2 ()
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
>#4  0x0205fda4 in dont_fix_pil2 ()
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
>Backtrace stopped: previous frame identical to this frame (corrupt
>stack?)
>(gdb)
>#0  _Terminate
>(the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
>is_internal=is_internal at entry=false,
>the_error=the_error at entry=34011320)
>    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
>#1  0x0203c454 in rtems_fatal (
>    source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
>    error=error at entry=34011320)
>    at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
>#2  0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131
>#3  0x0205fda4 in dont_fix_pil2 ()
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
>#4  0x0205fda4 in dont_fix_pil2 ()
>    at
>../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
>Backtrace stopped: previous frame identical to this frame (corrupt
>stack?)
>(gdb)
>
>
>[1] I am not feeling 100% well and am at home today. So don't have
>access to everything not inclination to hunt.
>
>
>On 4/1/2014 10:21 AM, Joel Sherrill wrote:
>> I am confused. Did you build RTEMS with --enable-cxx?
>>
>> Did you make the linkcmds changes discussed?
>>
>> In RTEMS, the C++ global constructors are called by the first thread
>> that executes. Before that, almost anything a constructor is allowed
>> to do that is not pure computation or memory initialization would
>> not be valid because the OS and tasking are not running.
>>
>> There is a call in _Thread_Handler to the constructor execution
>method.
>> The name varies by target so it is a macro named INIT. A few lines of
>code
>> later the user init task is invoked.
>>
>> Let's keep this on rtems-users so others benefit from the discussion.
>>
>> --joel
>> On 3/27/2014 9:00 PM, Thomas (Gmail) wrote:
>>> On referencing, I misunderstood that _init() call not C++
>constructor
>>> function because there is not C++ constructor function in crti.o.
>>>
>>> Today, after I make object dump file about elf file(cxx_throw.exe),
>I
>>> checked that below objdump information. It included ++ constructor
>as
>>> like below;
>>>
>>> 02066130 <_init>:
>>>  2066130:9d e3 bf a0 save  %sp, -96, %sp
>>>  2066134:7f fe 6c 60 call  20012b4 <frame_dummy>
>>>  2066138:01 00 00 00 nop 
>>>  206613c:7f ff e8 99 call  20603a0 <__do_global_ctors_aux>
>>>  2066140:01 00 00 00 nop 
>>>  2066144:81 e8 00 00 restore 
>>>  2066148:81 c3 e0 08 retl 
>>>  206614c:01 00 00 00 nop 
>>>
>>> I am sorry for my misunderstanding.
>>>
>>> Best Regards
>>>
>>>
>>> 2014-03-28 10:19 GMT+09:00 Thomas (Gmail) <thomas73.kim at gmail.com
>>> <mailto:thomas73.kim at gmail.com>>:
>>>
>>>     Please check that my modification is correct.
>>>
>>>     I modified linkcmds.base according to your comment.
>>>
>>>     (Before)
>>>         KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>>>         KEEP (*(SORT(.ctors.*)))
>>>         KEEP (*(.ctors))
>>>         KEEP (*crtbegin.o(.dtors))
>>>         KEEP (*crtbegin?.o(.dtors))
>>>         KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>>>         KEEP (*(SORT(.dtors.*)))
>>>         KEEP (*(.dtors))
>>>
>>>     (After)
>>>         KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>>>         KEEP (*(SORT(.ctors.*)))
>>>         KEEP (*(.ctors*))
>>>         KEEP (*crtbegin.o(.dtors))
>>>         KEEP (*crtbegin?.o(.dtors))
>>>         KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>>>         KEEP (*(SORT(.dtors.*)))
>>>         KEEP (*(.dtors*))
>>>
>>>     Also, I compared map file.
>>>
>>>     (Before)
>>>      *(.ctors)
>>>      .ctors         0x0206040c        0x4
>>>     /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o
>>>      *crtbegin.o(.dtors)
>>>      .dtors         0x02060410        0x4
>>>     /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o
>>>      *crtbegin?.o(.dtors)
>>>      *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
>>>      *(SORT(.dtors.*))
>>>      *(.dtors)
>>>
>>>     (After)
>>>     *(.ctors*)
>>>      .ctors         0x0206040c        0x4
>>>     /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o
>>>      *crtbegin.o(.dtors)
>>>      .dtors         0x02060410        0x4
>>>     /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o
>>>      *crtbegin?.o(.dtors)
>>>      *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
>>>      *(SORT(.dtors.*))
>>>      *(.dtors*)
>>>      
>>>     Best Regards
>>>
>>>
>>>     2014-03-28 2:00 GMT+09:00 Joel Sherrill
>>>     <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>:
>>>
>>>         I am out of the country and teaching this week. Trying
>adding an
>>>         "*" after ctors and before the parentheses. Ditto for dtors
>>>         so it wild
>>>         card matches.
>>>
>>>         Look at how .text has a * on it
>>>         On 3/27/2014 10:25 AM, Thomas (Gmail) wrote:
>>>>         I am tring to compare linkcmd.base and toolchain's
>>>>         elf32_sparc.x.
>>>>         But, I am difficult to modify linkcmd.base for this.
>>>>
>>>>         Please could you send to me the revised linkcmd.base file ?
>>>>
>>>>
>>>>
>>>>         2014-03-27 18:18 GMT+09:00 Joel Sherrill
>>>>         <joel.sherrill at oarcorp.com
><mailto:joel.sherrill at oarcorp.com>>:
>>>>
>>>>             libgcc2 is already in the toolset. This almost 100%
>>>>             certainly is a small
>>>>             bug in
>>>>             c/src/lib/libbsp/sparc/shared/startup/linkcmds.base. 
>Look
>>>>             at how the .ctors are referenced in the files
>>>>             elf32_sparc.x* installed
>>>>             as part of the toolset in
>>>>             $prefix/sparc-rtems4.11/lib/ldscripts. They
>>>>             have "." and a "*" in the KEEP lines. I don't think we
>>>>             have that.
>>>>
>>>>             The problem was almost certainly introduced with
>>>>             function sections
>>>>             being used and I missed a wildcard on the ctor/dtor
>lines.
>>>>
>>>>             On 3/27/2014 3:04 AM, Thomas (Gmail) wrote:
>>>>>             On referencing, I am a beginner regarding this.
>>>>>
>>>>>             As I know from googling information, name of the
>>>>>             section for constructor is in .ctors section in
>>>>>             linkcmds.base.
>>>>>             below reference code is from
>gcc-4.8.2/libgcc/libgcc2.c
>>>>>             because __do_global_ctors() function is in libgcc2.c,
>I
>>>>>             tried to add libgcc.a in rtems building environment.
>>>>>             but, I didn't complete.
>>>>>
>>>>>             < libgcc2.c >
>>>>>            
>----------------------------------------------------------------------------------------------------
>>>>>             /* Run all the global destructors on exit from the
>>>>>             program.  */
>>>>>             void
>>>>>             __do_global_ctors (void)
>>>>>             {
>>>>>             #ifdef EH_FRAME_SECTION_NAME
>>>>>               {
>>>>>                 static struct object object;
>>>>>                 __register_frame_info (__EH_FRAME_BEGIN__,
>&object);
>>>>>               }
>>>>>             #endif
>>>>>               DO_GLOBAL_CTORS_BODY;
>>>>>               atexit (__do_global_dtors);
>>>>>             }
>>>>>            
>-------------------------------------------------------------------------------------
>>>>>
>>>>>             < gbl-ctors.h>
>>>>>            
>-------------------------------------------------------------------------------------
>>>>>             /* Some systems use a different strategy for finding
>the ctors.
>>>>>                For example, svr3.  */
>>>>>             #ifndef DO_GLOBAL_CTORS_BODY
>>>>>             #define DO_GLOBAL_CTORS_BODY						\
>>>>>             do {									\
>>>>>               unsigned long nptrs = (unsigned long)
>__CTOR_LIST__[0];		\
>>>>>               unsigned i;								\
>>>>>               if (nptrs == (unsigned long)-1)				        \
>>>>>                 for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0;
>nptrs++);		\
>>>>>               for (i = nptrs; i >= 1; i--)						\
>>>>>                 __CTOR_LIST__[i] ();						\
>>>>>             } while (0) 
>>>>>             #endif
>>>>>            
>-------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>             2014-03-27 16:33 GMT+09:00 Joel Sherrill
>>>>>             <joel.sherrill at oarcorp.com
>>>>>             <mailto:joel.sherrill at oarcorp.com>>:
>>>>>
>>>>>
>>>>>                 On 3/27/2014 2:30 AM, Sebastian Huber wrote:
>>>>>                 > On 2014-03-27 06:28, Thomas (Gmail) wrote:
>>>>>                 >> I am tring to add libgcc.a in linking process
>>>>>                 for calling __do_global_ctors().
>>>>>                 > If you have to do this by hand, then your build
>>>>>                 process is broken.  How did you
>>>>>                 > get the RTEMS tool chain?  Which RTEMS version
>do
>>>>>                 you use?
>>>>>                 >
>>>>>                 >> Please could you let me know how to add
>libgcc.a
>>>>>                 in RTEMS building environment ?
>>>>>                 >>
>>>>>                 >> If this approach is not correct, please let me
>>>>>                 know correct how-to-do for C++
>>>>>                 >> global constructor for Sparc.
>>>>>                 > It should work out of the box.
>>>>>                 >
>>>>>                 Just out of curiosity what is the name of the
>>>>>                 section that the
>>>>>                 constructor is in?
>>>>>
>>>>>                 When I turned on function sections, it may now be
>>>>>                 in .initXXX instead of
>>>>>                 just .init.
>>>>>                 This would mean that an asterisk is needed in the
>>>>>                 linkcmds.base for init
>>>>>                 and fini
>>>>>                 to pick up all the methods. There is a KEEP()
>>>>>                 around them which I
>>>>>                 thought might
>>>>>                 be the issue.
>>>>>
>>>>>                 --
>>>>>                 Joel Sherrill, Ph.D.             Director of
>>>>>                 Research & Development
>>>>>                 joel.sherrill at OARcorp.com
>>>>>                 <mailto:joel.sherrill at OARcorp.com>        On-Line
>>>>>                 Applications Research
>>>>>                 Ask me about RTEMS: a free RTOS  Huntsville AL
>35805
>>>>>                 Support Available                (256) 722-9985
>>>>>
>>>>>
>>>>
>>>>             -- 
>>>>             Joel Sherrill, Ph.D.             Director of Research &
>Development
>>>>             joel.sherrill at OARcorp.com
><mailto:joel.sherrill at OARcorp.com>        On-Line Applications Research
>>>>             Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>>             Support Available                (256) 722-9985
>>>>
>>>>
>>>
>>>         -- 
>>>         Joel Sherrill, Ph.D.             Director of Research &
>Development
>>>         joel.sherrill at OARcorp.com <mailto:joel.sherrill at OARcorp.com>
>       On-Line Applications Research
>>>         Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>         Support Available                (256) 722-9985
>>>
>>>
>>>
>>
>> -- 
>> 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
>
>-- 
>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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140401/64777b5c/attachment.html>


More information about the users mailing list