On Fri, Mar 21, 2014 at 11:12 AM, JunBeom Kim (Coressent) <jb...@coressentkorea.co.kr> wrote: > Dear Gedare, > > Thank you for your reply. > > First of all, I set breakpoint in _Unwind_RaiseException. also, software > crash is occurred in _Unwind_RaiseException function certainly. > > When I see location of address 0x02034A43, it's location is > classify_object_over_fdes. > As I check google search with "classify_object_over_fdes C++ exception", I > am guessing that there is a bug in binutils. > > On referencing, I built sparc-rtems4.11-xxx toolchain according to > http://www.rtems.org/wiki/index.php/Building_Tools > > If possible, please let me know your advice for next step. > Try using the RSB to build your tools: http://www.rtems.org/wiki/index.php/RSB
> Best Regards, > JunBeom > > -----Original Message----- > From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of > Gedare Bloom > Sent: Friday, March 21, 2014 9:38 PM > To: JunBeom Kim (Coressent) > Cc: RTEMS Devel > Subject: Re: C++ Exception Test Failure on Sparc SIS. > > On Fri, Mar 21, 2014 at 2:42 AM, JunBeom Kim (Coressent) > <jb...@coressentkorea.co.kr> wrote: >> Dear Sir, >> >> >> >> After I built RTEMS kernel for Sparc SIS, I downloaded examples-v2. >> >> Also, I am testing cxx example. >> >> >> >> When I test cxx example on SIS, C++ exception(throw->catch) is not > working. >> >> Console message is below; >> >> >> >> SIS - SPARC instruction simulator 2.7.5, copyright Jiri Gaisler 1995 >> >> Bug-reports to jg...@wd.estec.esa.nl >> >> >> >> sis> load cxx_throw.exe >> >> sis> go >> >> resuming at 0x02000000 >> >> Hey I'm in base class constructor number 1 for 0x2081318. >> >> Hey I'm in base class constructor number 2 for 0x2081320. >> >> Hey I'm in derived class constructor number 3 for 0x2081320. >> >> >> >> >> >> *** CONSTRUCTOR/DESTRUCTOR TEST *** >> >> Hey I'm in base class constructor number 4 for 0x208c724. >> >> Hey I'm in base class constructor number 5 for 0x208c71c. >> >> Hey I'm in base class constructor number 6 for 0x208c714. >> >> Hey I'm in base class constructor number 7 for 0x208c70c. >> >> Hey I'm in derived class constructor number 8 for 0x208c70c. >> >> Testing a C++ I/O stream >> >> before try block >> >> Unexpected trap ( 7) at address 0x02034A54 >> >> memory address not aligned >> >> IU in error mode (257) >> >> 826787 02036f14 91d02000 Address 0x02036f14 is out of bounds. >> >> >> >> I want to know how to receive this problem. >> > > Use sparc-rtems-4.11-objdump -d option to disassemble the executable binary, > then see what is the location of address 0x02034A54. Set a breakpoint in > debugger at that function, see what memory address is causing the alignment > fault. Determine where the memory address gets computed, and why there is an > alignment problem. The compiler should not cause an alignment problem unless > it gets the wrong flags or the code uses some tricks to coerce data types, > so perhaps the code where the fault happens has got a bad set of compiler > flags. > > That's where I would start anyway. Good luck, Gedare >> >> >> Best Regards, >> >> JunBeom Kim >> >> >> >> >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel >> > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
