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.sherr...@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.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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
