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