C++ Exception Test Failure on Sparc SIS.

[Gedare Bloom]

On Fri, Mar 21, 2014 at 12:45 PM, JunBeom Kim (Coressent)
<jbkim at coressentkorea.co.kr> wrote:
> Dear Gedare,
>
> After installing all toolset according to RSB, I rebuilt rtems source tree
> for SIS.
> When I check this, current problem is not resolved.
> I think that this problem is not related with toolchain by RSB.
>
OK, this means there may be a real bug in the current toolchains!

I have just duplicated your result with my toolchain and build of examples-v2.

> Please could you let me know another option for resolving this ?
>
The next step is to figure out what is going wrong in
classify_object_over_fdes(), which appears to be in libgcc not
binutils. This will take some investigating to see what line of code
causes the alignment problem, figure out what that line of code is
doing, and think about why a mis-alignment might be happening. Then a
bug report can be filed with gcc.

-Gedare

> Best Regards,
> JunBeom
>
> -----Original Message-----
> From: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf Of
> Gedare Bloom
> Sent: Saturday, March 22, 2014 12:29 AM
> To: JunBeom Kim (Coressent)
> Cc: RTEMS Devel
> Subject: Re: C++ Exception Test Failure on Sparc SIS.
>
> On Fri, Mar 21, 2014 at 11:12 AM, JunBeom Kim (Coressent)
> <jbkim at 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: gedare at gwmail.gwu.edu [mailto:gedare at 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)
>> <jbkim at 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 jgais at 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 at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>
>>
>