RTEMS C++ global constructor for Sparc

Joel Sherrill joel.sherrill at OARcorp.com
Tue Apr 1 20:36:59 UTC 2014


On 4/1/2014 3:09 PM, Daniel Hellstrom wrote:
> 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.
>
OK.  The 0x80 indicates synchronous trap:

/**
 * This macro indicates that @a _trap as a synchronous trap.
 */
#define SPARC_SYNCHRONOUS_TRAP( _trap )     ((_trap) + 256 )

How about 137 or 0x87 which makes it a type of trap?

It is happening in classify_object_over_fdes if that helps.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140401/c371a7fb/attachment-0001.html>


More information about the users mailing list