RTEMS C++ global constructor for Sparc

Joel Sherrill joel.sherrill at OARcorp.com
Thu Apr 3 22:06:23 UTC 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140403/46ecdf27/attachment.html>


More information about the devel mailing list