RTEMS C++ global constructor for Sparc

Joel Sherrill Joel.Sherrill at OARcorp.com
Thu Apr 3 22:30:36 UTC 2014


I think I have a real fix for this. I will confirm and commit it in the morning if I am right.

On Apr 3, 2014 5:04 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
The problem appears to be a missing "KEEP" directive in the
linkcmds shared across the sparc BSPs.

I proved this by reverting the patch to do per function/variable
sections.

The long term fix is to see what sections have KEEP() in
$prefix/sparc-rtems4.11/lib/ldscripts and see which one was
missed in the RTEMS version of this.

But this patch is a short term fix

diff --git a/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg b/c/src/lib/libb
index 2859372..3ee9ca8 100644
--- a/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg
+++ b/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg
@@ -13,6 +13,6 @@ CPU_CFLAGS = -mcpu=cypress

 # optimize flag: typically -O2
 CFLAGS_OPTIMIZE_V = -O2 -g
-CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
+# CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections

-LDFLAGS = -Wl,--gc-sections
+# LDFLAGS = -Wl,--gc-sections

On 4/2/2014 9:27 AM, Thomas Kim wrote:
Hi,

I didn't use --enable_cxx option because this option is C++ class API for rtems native c api.
Is it correct ?
Also, the reason about address unalignment is that the base address pointer for eh_frame is located on ctor_list. ctor_list is used for C++ global constructor.

After I modifed linkcmd.base for sis, eh_frame is generated. but, there is still a problem in classify_object_over_fdes() because CIE information is not correct.

If correct eh_frame section is generated, maybe, C++ throw handler will be worked.

If you have any idea for this, please let me know that.

Best Regards,
Thomas



2014-04-02 6:19 GMT+09:00 Joel Sherrill <joel.sherrill at oarcorp.com<mailto:joel.sherrill at oarcorp.com>>:

On 4/1/2014 4:10 PM, Cláudio Silva wrote:
> If you are receiving trap 263 it should mean that you are receiving
> trap 7 when subtracted with the synchronous bit. Trap 7 is memory
> address not aligned in sis?
It is and all SPARC BSPs use the same linkcmds.

This may be dereferencing a special section which is not aligned
enough.  C++ has
a number of them. The question is:

   What does the method classify_object_over_fdes() really do?

Once we know the section(s) it uses, aligning it is easy.

--joel
> .
> On Tue, Apr 1, 2014 at 9:36 PM, Joel Sherrill <joel.sherrill at oarcorp.com<mailto:joel.sherrill at oarcorp.com>> wrote:
>> 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<mailto: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<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
>>
>> --
>> 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<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
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org<mailto:rtems-users at rtems.org>
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>

--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140403/1acd22f8/attachment-0001.html>


More information about the devel mailing list