Segmentation fault in exec_dt_buffer(), problem in Dynamic_Translator?

[GoogleCodeExporter]

Steps to reproduce
1. Use 
   - ARMware ver. 0.4.7 (download package) or svn_rev_27
   - Fedora-8 (2.6.23.1-42.fc-8), gcc-4.1.2 and compatible dependencies
      or 
     Fedora-9, gcc-4.3.0 and compatible dependencies
   My host_CPU is Intel_Pentium_4 (3.00GHz), 1MB cache.

2. Build with ENABLE_DYNAMIC_TRANSLATOR=true (default setting)
   in options.mak

3. Run <ARMware_root>/bin/armware.
   Machine characeristics
   - Screen width:  240
     Screen height: 320
   - Image: 
     Total ROM file-size = 128MB
     1 Name:  bootldr.bin (as downloaded)
       Size:  256KB
       pos :  0x00000000
     2 Name:  root.bin (as downloaded)
       Size:  16128KB
       pos :  0x00040000

4. Select the above-created machine and start.

The execution ends with a SIGSEGV at 
Core.cpp, function 'exec_dt_buffer(), line_#1392.


Futher experiment
-----------------

I tried to re-build with 
ENABLE_DYNAMIC_TRANSLATOR=false in options.mak.
With this setting, the bootloader runs fine, but 
while copying the kernel, the following assertion 
is observed:
 File     : InstDPI.tcc: 2489
 Function : void ARMware:<unnamed>:OperationInternal_Helper(
                        ARMware::InstDPI<ARMware::TST, mode, 
                             UPDATE_STATUS,T_usage, 
                             update_status_category_id,
                             operand_number_category_id>* )

            with mode = ARMware::ImmDPI, 
            ARMware::UsageEnum T_usage = USAGE_NORMAL,
            update_status_category_id = 
                    ARMware::UpdateStatusCategory <
                        ARMware::OpcodeHasToUpdateStatus>::
                            UpdateStatusCategoryId,
            operand_number_category_id = 
                    ARMware::OperandNumberCategory <
                        ARMware::OperandNeedRd>::OperandNumberCategoryId

 Assertion: "0 == (dpi->m_inst.mRawData & 0xF000)"

Kindly let me know if there is an easy fix to this, or whether this is 
important enough to be logged as another issue.


Thanks,
Mankawal

Original issue reported on code.google.com by mankawal...@gmail.com on 20 Jan 2009 at 11:00