RTEMS C++ global constructor for Sparc

Cláudio Silva claudiodcsilva at gmail.com
Tue Apr 1 20:28:12 UTC 2014


Hello,

The addition of 0x100 is a convention to represent the difference
between synchronous and asynchronous traps.

Cláudio

On Tue, Apr 1, 2014 at 9:09 PM, Daniel Hellstrom <daniel at gaisler.com> 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.
>
> 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>:
>>>
>>> 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>:
>>>>
>>>> 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>:
>>>>>
>>>>> 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>:
>>>>>>
>>>>>>
>>>>>> 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        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
>>>
>>>
>>
>>
>> --
>> 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.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>




More information about the users mailing list