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.sherr...@oarcorp.com > <mailto:joel.sherr...@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.sherr...@oarcorp.com <mailto:joel.sherr...@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.sherr...@oarcorp.com <mailto:joel.sherr...@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@entry=RTEMS_FATAL_SOURCE_EXCEPTION, > >>> is_internal=is_internal@entry=false, > >>> the_error=the_error@entry=34011320) > >>> at > ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36 > >>> 36 { > >>> (gdb) bt > >>> #0 _Terminate > (the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, > >>> is_internal=is_internal@entry=false, > >>> the_error=the_error@entry=34011320) > >>> at > ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36 > >>> #1 0x0203c454 in rtems_fatal ( > >>> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, > >>> error=error@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@entry=RTEMS_FATAL_SOURCE_EXCEPTION, > >>> is_internal=is_internal@entry=false, > >>> the_error=the_error@entry=34011320) > >>> at > ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36 > >>> #1 0x0203c454 in rtems_fatal ( > >>> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, > >>> error=error@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....@gmail.com <mailto:thomas73....@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.sherr...@oarcorp.com <mailto:joel.sherr...@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.sherr...@oarcorp.com <mailto:joel.sherr...@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.sherr...@oarcorp.com <mailto:joel.sherr...@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.sherr...@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.sherr...@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.sherr...@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.sherr...@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.sherr...@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.sherr...@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-us...@rtems.org <mailto:rtems-us...@rtems.org> > >> http://www.rtems.org/mailman/listinfo/rtems-users > >> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@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.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel